Construct 3 Spine Plugin

Fine. None of the two companies have the opportunity to develop a plugin. As a result, a large number of developers and potential customers of both companies do not use them products.

The community has several freelance plug developers.

That's the obvious solution.

Agreed with Newt - the solution is to crowdsource a plugin. We could look at getting a form of community pot/ plugin bounty going?

The issue as far as I can see is that then we'd have the following problems:

A) Both Scirra and Spine could disavow the plugin as being developed by a third party

B) We would be beholden to the third party to update this plugin

C) The cost of outsourcing programming at a fair hourly rate would far eclipse the cost of the tools themselves

I guess we can only appeal to the cold heart of capitalism and hope that an enterprising dev sees that there's market demand for this plugin (and that he/she then sells it for a compelling price)

Another problem is that the api developer would have to learn our api.

Luckily Lucid was already a member of the community, or we might not even have Spriter.

Ashley Thank you for the explanation :)

Elliott I would support the crowdfunding about making a plugin for the spine, dragonbones, flare or any other animation tool that has mesh feature.

PixelSwanGames

I supported spriter 2 and bought it. Because they announced a demo at the beginning of the year. A YouTube video trailer for more than a year. As a result, at the beginning of the year we received nothing and even now there is nothing.

But spine is already a finished program with a lot of functions.

It's not a Spine plugin, but I'm playing with JS integration of the Spine-TS (webgl) runtime. It will require more direct C3 JS scripting to control the Spine-TS api. I am using Spine-TS to render to a separate canvas and then capture the canvas and update a sprite with the rendered image each frame.

It's currently working, but with one caveat, every few seconds it stutters (it looks like due to JS Garbage collection, there's another thread about that in the forum asking for help on a solution.)

You will need to use JS to control it, so it will require some C3 JS knowledge. The current template is more of a tech demo and would need a lot of clean up to be used in a game, but's promising to see something work.

Here's an example of it in action in C3 (I'm also enabling the display mesh and display bones options on and off.)

Mikal

It looks great!

I would like to ask. Is this just an example that spine can work with C3? Or could it be more than a demonstration of an animation mesh?

q3olegka Sorry, I'm not sure I understand your question. This is a Spine skeleton, animations, and atlas imported into C3 from Spine (_not_ done with exporting spritesheets from Spine.) The Spine-TS JS runtime is also imported into C3 (via JS script files) to render the animation to a canvas each frame. The canvas image is then loaded into a C3 sprite animation frame on each tick. The original Spine animation and skeleton are using mesh (you can see the animation mesh deform as it moves.) The Spine animation could be controlled dynamically by C3 JS scripting events which use the Spine-TS JS API.

At this stage, it's a C3 tech demo to see if it's possible to use the Spine-TS JS runtime as an alternative to waiting for someone to do a full C3 plugin / port to C3 SDK. If it works reliably (there is a stuttering issue every few seconds which I am tracking down), I'll make a template and share it.

Did I answer your question?

Mikal

Yes, thank you! :)

One more question. Will there be a performance difference when compared to frame-by-frame animation, except a smaller memory requirement?

Yes, I think Spine and Spriter animation in C3 will take more performance than frame by frame (though with the benefit of potentially lower memory footprint and more flexibility of controlling the animations during runtime.) It's a tradeoff. Exporting png Spritesheets from Spine and Spriter is also a reasonable solution with different tradeoffs.