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?

Image removed due to the lack of support for HTTPS. | Show Anyway

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 wrote

Image removed due to the lack of support for HTTPS. | Show Anyway

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.

Image removed due to the lack of support for HTTPS. | Show Anyway

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.