Maltakreuz

I have a pretty complex character with clothing/ammo/skins etc. If i make a lot of copies it will be rendered in wrong order:



Probably because multiple materials used:


If i add SortingGroup the "bug" seems to be fixed.



It works fine, but do i really need that to make spine skeleton be rendered in correct order? For another (not so complex) skeletons everything will be rendered just find without this SortingGroup. I googled and found out, that SortingGroup is used for some advanced spine-render techniques, like render skeleton parts by parts and like that. But i do nothing special, just straightforward default normal rendering. Is it bug in unity runtime? Or why i need SortingGroup?
User avatar
Maltakreuz
  • Posts: 44

Harald

If you are using lightweight/universal render pipeline, this is a bug in Unity of too agressive batching. For this we have added a parameter Fix Draw Order in the Advanced section of the SkeletonRenderer inspector.

Aside from the issue: Why do you need 7 different atlas pages for this rather simple character setup? It seems as if you haven't grouped the attachments by the criterion of minimizing draw calls.
User avatar
Harald

Harri
  • Posts: 2091

Maltakreuz

Harald wrote:Aside from the issue: Why do you need 7 different atlas pages for this rather simple character setup? It seems as if you haven't grouped the attachments by the criterion of minimizing draw calls.
Yes, i am still using unity 2018 so it sholuld be old "URP". So Fix Draw Order is somehow better bugfix for that as SortingGroup? Or is it identical? Ok, thank you, at least i know now this is a common problem with well known workaround.
Harald wrote:Aside from the issue: Why do you need 7 different atlas pages for this rather simple character setup? It seems as if you haven't grouped the attachments by the criterion of minimizing draw calls.
Well i really have pretty many different clothings. They could be used theoretically independent, but normally they are used as "costume" with same sprites.

But how can i control what sprite lands in which atlas?

upd: tryed to fix the same bug with FixDrawOrder checkbox instead of Sorting Group: it changes draw order indeed, but still makes it false. Sorting Group however works correctly in my case. So i better stay with Sorting Group solution.

upd 2:
Just read about exporting atlases, it should be acutally done automatically for sprites from one folder, which is the case for my clothes, but somehow sprites are sorted by size i would say, not by belonging to the same folder. Is something wrong with my pack settings?



That's the folder for one costume on HDD (so theese sprites should land on the same page)



But actually they are only partly on the same page:



Some skirts are really on the same page. But all small parts are somewhere else.

Can i somehow force packing to mandatory pack all sprites from same folder in same page? It could really reduce material amount for each npc.
User avatar
Maltakreuz
  • Posts: 44

Harald

You can find documentation about packing using folder structure here:
Texture Packing - Spine User Guide: Folder structure
Also be sure to read this section here:
Texture Packing - Spine User Guide: Packing during skeleton data export
User avatar
Harald

Harri
  • Posts: 2091

CarrotPie

We have similar layer glitches happening in our game. Cannot use sorting groups - they brake GPU instancing by default. "fig draw order" option does nothing. Tried out different shaders none of which seem to work (also shaders form Spine-unity package do not support GPU instancing anyways). Adjusting camera angle a bit fixes sorting only partially - animations still keep glitching layers through each other (actually 1 particular layer on all skins and only some animations, not all), but intersections between objects seem to be fixed. Everything looks fine when animations run in Spine.

Any advice how to fix those layers and have GPU Instancing on spine objects at the same time?

Seems like we have tried it all to try to improve the performance (so no need to quote other solutions) and finally come up to the conclusion that the only viable way to go is GPU instancing...

We import using JSON, single texture atlas. Unity version 2019.3.14.
CarrotPie
  • Posts: 9

Harald

CarrotPie wrote:We have similar layer glitches happening in our game.
We are sorry to hear that. Could you please send us a minimal Unity project that still shows the problem as a zip package (not unitypackage) to contact@esotericsoftware.com, we would really like to fix this issue.
CarrotPie wrote:Seems like we have tried it all to try to improve the performance (so no need to quote other solutions) and finally come up to the conclusion that the only viable way to go is GPU instancing...
Do you see any performance increase on Spine Skeletons when using a shader with GPU instancing enabled? I wonder how GPU instancing gains you anything here as Spine Skeleton vertices are animated on the CPU (as some Spine features cannot be transferred to transform matrices). Enabling GPU instancing disables batching (which might anyway not happen when using too many vertices, etc), so you might end up with worse performance with enabled GPU instancing on some devices. If you have a use case however where instancing indeed provides you with performance benefits, please send us a small Unity project that demonstrates this, we are happy to add GPU instancing support to the Spine shaders.
User avatar
Harald

Harri
  • Posts: 2091

CarrotPie

Hey, Herald. Thank's for insights, I will try to assemble an example project scene readied with the visible glitches.

Regarding GPU instancing:
We've been instancing the map, so figured we could do the same with units. But it could as well be that the choke point is the CPU part, since we'll be running the game on a browser, it's likely. In profiler, though, it is obvious that most of the cost comes from graphics (or CPU waiting for frame to render), second most - playing spine animations. Actual game code is marginally negligible in that context...

Concerning batching:
AFAIK alpha breaks any kind of batching, so didn't even try it yet. Sadly have not yet succeeded to enable GPU instancing on spine objects (thus the question in previous post), so of course got no example of possible performance benefits. There's a truly limited amount of performance solutions with Spine objects in Unity and sadly we cannot find a working one. It would be nice if there was a reference document online, explaining how Spine plugin works and advice on what to use for performance - not how to animate, there is plenty of that - but how to approach within the engine.
CarrotPie
  • Posts: 9

Harald

CarrotPie wrote:Regarding GPU instancing:
We've been instancing the map, so figured we could do the same with units.
This will not benefit you when the animated units are animated on the CPU and transformed vertices uploaded to the GPU.
CarrotPie wrote:AFAIK alpha breaks any kind of batching, so didn't even try it yet.
Unity will batch typical Spine skeletons with alpha as well. That is unless you disable batching, if you mean that by "didn't even try it yet".
CarrotPie wrote: Sadly have not yet succeeded to enable GPU instancing on spine objects (thus the question in previous post), so of course got no example of possible performance benefits.
You would need to use a non-Spine shader, and then enabling it will not provide you with any benefits, as described above.
CarrotPie wrote: It would be nice if there was a reference document online, explaining how Spine plugin works and advice on what to use for performance
Thanks for the input. We understand your demand and will add such a section to the spine-unity documentation pages in the future. Nevertheless, if there was a magic bullet available, we would let you know or enable it by default - unfortunately there is no magic setting.

General rules apply for all supported runtimes and engines, and these are to keep the number of atlas pages and materials to a minimum (this implicitly reduces draw calls and allows batching), and reduce the number of vertices, bones, constraints where possible, and avoid clipping attachments.

The only recommendation specific for the spine-unity runtime would be to:
  • Repack skins at runtime to a single atlas page (as in the Mix and Match example scenes) to merge multiple atlas pages to one.
  • Disable the SkeletonAnimation component on GameObjects that are offscreen to prevent the animation overhead. We have an issue ticket on the roadmap to provide this feature as a comfortable Inspector parameter.
  • Keep vertex count below Unity's batching threshold if possible.

We also have optimizations planned for the spine-unity runtime, a task that I would love to get to work on. Unfortunately some higher priority tasks and answering questions on the forum delays this starting point.
User avatar
Harald

Harri
  • Posts: 2091

CarrotPie

Thank you for the answer, sorry to bother, but I believe performance is vital information for many developers, who are not doing a straight forward / simple game, but try to innovate with ideas.
Harald wrote:This will not benefit you when the animated units are animated on the CPU and transformed vertices uploaded to the GPU.
Glad it's cleared up now, seems I was heading the wrong way.
Harald wrote:Unity will batch typical Spine skeletons with alpha as well. That is unless you disable batching, if you mean that by "didn't even try it yet".
Did not disable batching. It is not batching anyways, I guess because of the aforementioned vertices count, will see if we can reduce it. Does Sorting Group beak dynamic batching though? Seems like it does...
Harald wrote:You would need to use a non-Spine shader, and then enabling it will not provide you with any benefits, as described above.
We tried using default unity sprites in that case, but seems this road has been closed.
Harald wrote:Keep vertex count below Unity's batching threshold if possible.
I will talk to our animator and will reducing the count next if possible.
Harald wrote:We also have optimizations planned for the spine-unity runtime, a task that I would love to get to work on. Unfortunately some higher priority tasks and answering questions on the forum delays this starting point.
Great news, although it looks like it's at the bottom of the task list, so I guess can expect it in a couple of years, not much sooner. Have tried the ECS/DOTS myself, it shows amazing performance, but it's difficult to get around the huge conceptual mindset change about how to organize and code it
Can't wait for the updates! Thanks again and sorry to bother.
CarrotPie
  • Posts: 9

Harald

CarrotPie wrote:Thank you for the answer, sorry to bother, but I believe performance is vital information for many developers, who are not doing a straight forward / simple game, but try to innovate with ideas.
I completely understand that. While it will mostly say "general rules of optimization apply", we will add such a section to the spine-unity docs to explicitly point that out.

Thanks for getting back to us!
CarrotPie wrote:Does Sorting Group beak dynamic batching though? Seems like it does...
Not in all cases, no. You can test for yourself, create a skeleton, duplicate it and look at the "saved by batching" stats. Then add SortingGroups.
User avatar
Harald

Harri
  • Posts: 2091


Return to Unity