Good job on the new version!

Has this made it into the beta? - https://waffle.io/EsotericSoftware/spine-editor/cards/574b9dc9b9f10c1e009137f4

Allow copy/paste of all objects between skeletons - v3.6 - In the "Ready" column.

8) :giggle: hi, i'm start for this website, please recommend me for everything, thank.

Any news on when the full release of 3.6 (not the beta) will be out? I just can´t wait. Good job.

We're also very interested to know when 3.6 and especially the masking feature will be out (for cocos2d-x). We'd love to use it for some nice zooming animations like the one below.

Also a question about it: Will the masking be handled at Spine-Export-Time (hence no performance impact at runtime) or at runtime? If it will be handled at runtime, what's the performance impact? Scissor, Stencil or Vertices manually calculated before rendering?

 Loading Image

It will be a combination of scissor and stencil. We have yet to find the best solution for cocos2dx. It will definitely break batching, so you shouldn't overdo it.

What do you think about using something like the Sutherland-Hodgman polygon clipping algorithm instead? This would perform all changes on the vertices at runtime and not break batching.

Wikipedia with images: https://en.wikipedia.org/wiki/Sutherland%E2%80%93Hodgman_algorithm
Here's a C++ implementation with some images at the bottom: http://www.pracspedia.com/CG/sutherlandhodgman.html
Another implementation with performance improvement ideas: http://codereview.stackexchange.com/questions/131852/high-performance-triangle-axis-aligned-bounding-box-clipping

I'm not sure if these implementations are the most performant but tons of these exist on the web, ready to get some action

I haven't ruled out software clipping yet. It'd be most portable, but then people would be upset about performance when they clip hundreds of skeletons per frame

There is a such big problem that Spine has version nearly 3.7 and Unity works with 3.5.43 which also isnt stable enough :/
Do you have plans to upgrade Spine-Unity cooperation ?

And what also interesting me, it would be nice to add visual option on the time line, to show pasted fragment. For example some bones animate from the frame 1-300 and others 1-100. When I want to have in move all objects like sparks etc I have to copy and paste those "others" 3 times to have 300 frames in total. But after this, sometimes it is hard to find where exacly I pasted those bones, especially when key frames are not so regullar or some1 back to the project after a time.

@badlogic Well, always those people using hundreds of skeletons

It really depends how clipping via scissor/stencil would be implemented.
Would it break batching completely? One draw call per clipped skeleton or one draw call for all clipped skeletons on the same texture/globalZ/etc. ?
If using scissor it would definitely take one glScissor call per Skeleton, since glScissor can't be batched.
As Stencil operates on fragments it also won't be cheap for many skeletons . I just checked the Cocos2d-x Stencil implementation and they're calling lots of openGl functions for every single node they render with stencil, ouch!

So yeah...it really depends how batching would be affected and how costly scissor/stencil will be. My gut feeling here is that software clipping will faster performance-wise and easier to use for the coders (batch rendering).

@framusrock neither scissor not stencil could be batched, at least not in Cocos2d-x. As i said, not ruling out software clipping, but Sutherland-Hodgeman may not work for our use case. Needs research.

@Wedrownik what specifically are you refering to with "isn't stable enough"? We are not "nearly 3.7". You can follow the 3.6-beta development on the branch at GitHub with the same name.

Hi, any blog update what is happening? We are going to produce short anim films with Spine and Unity and would like to know a bit about status quo of Spine. Thank you, Marek.

We are finalizing editor support for two color tinting, local/relative transform constraints and clipping (which might or might not make it into 3.6). You can find an up-to-date changelog for the editor at Spine: Changelog. The changelog for the runtime can be found here spine-runtimes/CHANGELOG.md at master

@badlogic, As it seems like clipping is not making it into 3.6, I'm about to implement it myself (and also culling, but that's a different story ) into Cocos2d-x. I plan to do it on the vertices / software clipping. You said that Sutherland-Hodgeman might not work for the Spine use-case. Could you elaborate on that? Do you have any other algorithm in mind that might work better?
I'm also about to research more before I do it, it sounded like you might have something in mind already.

Cool! Sutherland-Hodgeman has limitations on the clipping polygon, e.g. no self-intersection etc. The way clipping is currently setup in the experimental editor branch is that we allow arbitrary, self-intersecting polygons. I haven't found an algorithm that could help us with this yet, we'll likely have to hack up our own interior/exterior detection for that.

Ahh okay. Well, we only need rectangle clipping for our use case, so it should work for that. But maybe there's an even more optimized algorithm for rectangles.

Nate a écrit

 Loading Image

Nice Animated clipping

Is it possible to put hands on this masking if I opt-in for beta? Is this supported with runtimes for Starling (AS3) and Game Maker (GWL)?

Seems like we've got some nice polygon clipping now

We're using the Sutherland-Hodgeman algorithm now since it's quite fast (although not the fastest) and we don't need arbitrary polygons.

It would be indeed nice to use Stencil, and it's also possible to batch draw with Stencil....just Cocos2d-x doesn't support it nicely. I did quite some research before resorting to software clipping.
You'd have to create your own StencilManager that keeps an eye on all Stencil rendered skeletons and then batches at first the Stencil draw calls to the Stencil buffer and afterwards the normal draw calls. I think that this would be the best solution for Spine, but it might take some time to implement.
Since we don't need that clipped skeletons, we did sacrifice a bit of performance here for an easier implementation. But sacrificing batch rendering is just not an option ever, it's creating a mess in the whole drawing hierarchy and it just costs a lot of performance.

 Loading Image

LegioXV, not it's not supported in Starling and GM runtimes yet (the latter is maintained by YoYoGames who'd need to add this functionality.

famusrock, that's awesome! Batching is much easier to retain with software clipping than with stencil. The latter, as you identified, introduces a lot of complications, and making it work with arbitrary rendering graphs without breaking batching is extremely hard. I'll try to figure out the best clipping algorithm for our use case. Since we only clip triangles against arbitrary polygons, there may be some tricks we can apply.

I should also note that no matter how we implement clipping, it will always incur runtime overhead. Nobody should apply it to all their skeletons in their scene, we will not be able to make it work fast enough in that case.

Badlogic, are there any timeline for updating Starling-spine runtimes to support this?
I'm asking, because missing mask feature makes my life really hard for doing some animations (even right now). So it's not just curiosity.

@LegioXV it will take some time, as starling doesn't support clipping in hardware at all. We'll need a software solution for this, which is a bit tougher to implement.

@framusrock I'll follow up with the cocos2dx guys. The path of least resistance for all runtimes is definitely software clipping, and I favor that at the moment.

Any news on when the update will be live?

Any updates on when the new version will be live?

We are still working on it. Check out the waffle for progress and things that have been done. You can filter by the 3.6 milestone to see open issues for that release.

Its great to have this.

After updating to beta I find out some veird issue.
All slots in Animate tinted blue with transparent alpha
http://i.imgur.com/ZGXWqZB.jpg

In my situation all slots in Setup should be with "alpha 0". That's requirement from our developers.
In Animate in 0 frame for all needed slots manualy sets up "alpha 255".
So that's maybe the reason but it's strange anyway.

this is the problem .... i gave 1% weight to a particular set of mesh points and when i move the bone the mesh goes crazy and weird ....
similar thing happened with another mesh but it was totally opposite ..... even if i gave 100% weight the mesh points didn't move single pixel .....

3.6 Release Date? Soon or still months of development?

Real soon now.

Spine-Unity for Spine 3.6 beta 1 unitypackage is now up.
See the download page for more info! Spine Unity Download

This also includes the recent AnimationState changes mentioned in the blog. Blog: AnimationState: multiple mixing without dipping