Hey, I just noticed in the Unity Profiler that the large 'menu' version of our character is causing anywhere from 8KB to 25KB of GC alloc per frame. Our small 'in-game' version that fits in one material does not generate garbage. The only difference between the two SkeletonData's is that the large one's atlas uses 3 PNGs/materials.

This will change depending on which skin I choose, which leads me to believe the GC alloc is happening because it might have some attachments in one material and some in another, though it's unclear why that has to cause so much allocations. I also tested just dragging the SkeletonData into a blank scene, so all that is running is the Spine skeleton, and it was the same.

Is this expected? If not what can I do? Debug it? Run-time material? I am okay with sharing the file too, privately.

Thanks.

P.S. this is on 3.6.

I believe so, it says this spine unity runtime works with 3.6.xx. I can try 3.7 though haven't gotten around to it since everything is fairly stable in our project right now haha.

Hey I figured out how to use Unity's deep profiler which gave some more information on this...

Note that this is still on Spine 3.6 export/Unity, but the code for AddSubmesh() appears to be the same in 3.7.

By debugging, it looks like meshGenerator.BuildMesh(currentInstructions, updateTriangles) is the culprit, but only if a skeleton has clipping in it as well as multiple atlases. If I turn on Single Submesh, or force clipping to off, then there is no GC alloc issues.

So for now I am going to work with our animator to remove all instances of clipping in the Spine file, and animate in any way possible without it.
It is also my guess that once we switch to doing run-time attachments/materials, then this problem would also go away...