Drawing plugins now supported in r68

Quickly chiming in here. lucid already described issues and potential fixes perfectly, so I'll refrain from pilling on here. I want to say that it's not our intention to push any specific setup on you, and that we agree that re-using as much of the Construct infrastructure as possible makes sense.

lucid - you've raised some good points, actually. Let me have a think about what we could do to solve some of these integration problems.

For rendering deformed meshes, are you currently drawing degenerate quads? (i.e. make two points of the quad the same, so you get a triangle)

he technique we use for constructing the meshes in Spriter 2 will easily adapt to either one. When I was experimenting with Construct 2's polys, whatever you had there was working fine. Regardless, whatever is most efficient will work for us.

Ashley, can you provide some help on migrating ept_link and ept_color from C2 to C3 format.

I'm guessing color can be handled by a link now, but it's not clear how to migrate links.

Some of the samples I've seen are:

new cr.Property(ept_link, "Image", lang("project\\misc\\tiledbg-edit-link"), "Click to edit the object's image.", "firstonly"),

new cr.Property(ept_link, "Sprite font", "Edit", "Click to edit the object's spritefont.", "firstonly"),

new cr.Property(ept_link, "Image", "Edit", "Click to edit the object's image.", "firstonly"),

new cr.Property(ept_link, "Animations", lang("project\\misc\\sprite-edit-link"), "Click to edit the object's animations.", "firstonly"),

new cr.Property(ept_link, "Size", lang("project\\misc\\sprite-make11-link"), "Click to set the object to the same size as its image.", "worldundo"),

new cr.Property(ept_link, "Sprite font", "Edit", "Click to edit the object's spritefont.", "firstonly"),

Thanks.

It looks like the SDK doesn't support color properties yet - I'll add that to the todo list.

Link properties work significantly different in C3, it's probably not easily possible to automatically convert them. In C2 they would call OnPropertyChanged() when clicked, but in C3 the property has a linkCallback option that is a JS function. In C2 the callback type defaults to (effectively) "for-each-instance", but you can specify a C2 option "firstonly" to only call on the first instance; in C3 this has been replaced by the "once-for-type" callback option, which instead passes an IObjectType to the callback rather than the first instance. I think the best you can do is create a stub function for the linkCallback, and put an instance parameter by default, or iObjectType parameter if the C2 plugin specifies "firstonly". Filling the function will just have to be a TODO comment, since it's probably too difficult to lift out the code from the property changed handler automatically, it's easier for the developer to do.

I can't figure out the color format:

new SDK.PluginProperty("color", "background-color", {initialValue:[1,0,1]}),

new SDK.PluginProperty("color", "background-color", {initialValue:"[1,0,1]"}),

If the initial value is the only option, you can just do:

new SDK.PluginProperty("color", "test-color", [1, 0, 0])[/code:2ybyl5ks]

Note: link-text needs to be added to https://www.construct.net/ca/make-games ... guage-file

Good catch, added it to that page.

So the drawing migration went fairly smoothly. I still have outstanding effects issues, if I could direct you to this thread, the issue is still there. It's unclear if this is a migration issue, or a bug, so I haven't posted an official bug report.

https://www.scirra.com/forum/effect-migration-issues_t196579

Thanks.

Has there been progress on supporting FFD/Mesh for the Spriter/Spine style plugins in the C3 Drawing SDK? Any comment on possible ETA?

I would like to use the FFD/Mesh animation directly, I am currently exporting a very large spritesheet to integrate into my game rather than using a plugin.

Ashley badlogic lucid

Mikal

The renderer in C3 is mostly the same as in C2. It's quad based, with some optimization for point rendering for particles.

Now, you can do mesh based stuff in spite of that. Basically it amounts to ending all rendering batches in the renderer and then using webgl directly. Just keep in mind any webgl state changes you do you have to revert back before Construct's renderer is to do something again. It may not be optimal, because it breaks batching, but it's still fast. Faster at the very least to just rendering a bunch of quads with the rendering api.

In my mind this update is mainly for being able to draw stuff in the editor. Then again I"m a bit out of touch with things.

You can render meshes using quads. It simply means you draw two adjacent triangles at a time. If there are an odd number of triangles, you can issue a single triangle by issuing a quad with two points at the same position, i.e. a triangle and a degenerate triangle. This isn't the fastest possible solution, but it's not bad, and more importantly it means you don't need to switch any of the WebGL state, which probably means it's a lot faster than trying to hack in a custom mesh renderer state.

I really, really would so much prefer Spriter and Spine to not implement themselves as drawing plugins. This forces the plugin to reimplement a bunch of Construct features and actually limits other creative features too. For example:

- you can't add a WebGL shader to just one part of a skeletal animation if the plugin draws the whole thing, but you can if it just controls sprite objects (e.g. make just the head flash red if hit, etc)

- you can't test for collisions with just a segment of a skeletal animation if the plugin draws the whole thing, but you can if it just controls sprite objects

- a plugin which draws the whole animation probably has to reinvent a whole asset management pipeline, but if it just controls sprites it leverages our project-wide in-editor spritesheeting engine

- Construct's support for containers allows you to treat composite objects as if they were one instance in the events

Personally I am convinced that these plugins should not use the drawing APIs and should simply act as controllers for sprites. This makes it much more flexible for the user, and avoids clunky reinventions of existing parts of Construct. I discussed this at length with a Spine developer a while ago and I thought they agreed; one of the outcomes of that discussion was the decision provide a custom import process so they can conveniently generate all the necessary sprites on import, so I filed this issue as a TODO for that work. Perhaps not all the Spine developers are aware of this approach.

We could add the drawing APIs they want, but one of the reasons we're holding off is because those features don't work in the canvas2d renderer. From the user's point of view, this will manifest as the plugin randomly not working on a small percentage of devices. I intend to make the C3 runtime the point where we unilaterally drop the canvas2d renderer, at which point we can go to town with these kinds of features. However even then it has the drawbacks listed above, and the C3 runtime is still some way off.

Rather than adding new drawing APIs, I would much rather add any extra APIs to allow them to act as controllers, and have a good workflow for importing and updating. That's why I filed the custom importers TODO issue. I am totally willing to co-operate with any developers who want to take this approach and refine the SDK to make it work well. I can't force them to, and they might make drawing plugins anyway, but I hope at least one of them take me up on this offer!

Hello,

Dev of Creature here. Creature is a 100% mesh based 2D deformation animation tool so mesh deformation ( and in particular, high performance per frame mesh deformation ) is key to really leverage its power.

We also do fancier skeletal mesh deformation beyond simple Linear Blend Skinning to achieve high quality curves/effects.

Ideally ( just like in almost any other game rendering engine ), we should be able to provide a list of points, indices and uvs and get the resulting mesh rendered out. This is a pretty standard API for any basic rendering pipeline. Rendering triangles as degenerate quads is not ideal even if the performance seems to be acceptable for some situations. Creature excels at high resolution meshes so again, performance is important.

I really want to support Construct 3 but a lot of the limitations regarding the renderer and what is provided to render simple meshes is lacking. Please let me know what I am missing here in order to achieve the level of visual fidelity on Construct 3 for the Creature animation tool.

Thanks

We will probably add dedicated mesh rendering functions for the C3 runtime, but until then I'd rather avoid it as there's no equivalent for the canvas2d renderer with the C2 runtime. If you want to ignore canvas2d support, you can use the quad rendering approach as an interim solution.

Any news about Spriter plugin for C3?