Этот сайт лучше всего просматривать в современном браузере с включённым JavaScript.

GC Alloc with multi-material Spine character

pixilestudios

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.

Harald

Allocations at first instantiation GC.Alloc count is expected to be high (mostly due to the many Bone objects being allocated), however per frame that is definitely not expected!

Are you using the last official 3.6 unitypackage? Have you checked if it is the same when upgrading a minimal test-project to 3.7?

pixilestudios

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...

Harald

Thanks for the additional info! I will look at the meshGenerator.BuildMesh and see if these allocations can be avoided. Anyway a potential improvement or bugfix will be included in the 3.7 and 3.8-beta runtimes, so the workarounds you described sound reasonable if you want to stay on 3.6.