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 - Сообщения: 1265
@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.

I'm also about to research more before I do it, it sounded like you might have something in mind already.
- framusrock
- Сообщения: 27
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.
-
badlogic - Сообщения: 1265
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.
- framusrock
- Сообщения: 27
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.


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.

- framusrock
- Сообщения: 27
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.
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 - Сообщения: 1265
badlogic, There was a thread in the cocos2d-x forums about stencil clipping being a problem and not being able to do easy batch rendering. I mentioned there that you guys are also struggling with it and improvements might be needed. Maybe nite from the cocos2d-x forums (or another cocos2d-x dev can help you guys with the stencil batching, or even fix it in cocos2d-x, so you'll have an easier live implementing it:
http://discuss.cocos2d-x.org/t/reduce-clippingrectanglenode-draw-calls/35143/7
http://discuss.cocos2d-x.org/t/reduce-clippingrectanglenode-draw-calls/35143/7
- framusrock
- Сообщения: 27
@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.
@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.
-
badlogic - Сообщения: 1265
- Davi Clean
- Сообщения: 35
- Davi Clean
- Сообщения: 35
-
Nate - Сообщения: 7881
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.
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.
-
AL32ander - Сообщения: 10
Strange, we haven't seen that. Can you please send a version of your .spine file that has not been saved with the beta? contact@esotericsoftware.com
---
We received your project, thanks! We've fixed the problem in 3.6.16-beta. Sorry for the trouble!
---
We received your project, thanks! We've fixed the problem in 3.6.16-beta. Sorry for the trouble!
-
Nate - Сообщения: 7881
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 .....
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 .....
-
Shiv - Сообщения: 46
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
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
Вернуться в Editor
- Удалить cookies конференции • Часовой пояс: UTC