- 수정됨
[Unity] SkeletonRenderer rebuilds everything each frame
Hi folks,
When we're using Spine animation in our unity game (4 characters running at the same time), we found that SkeletonRenderer.LateUpdate is always on the top 3 CPU eater in profiler. And it seems that this component is trying to rebuild the whole mesh every frame. Is there any potential performance improvements that we can make? (by sacrificing some memory, and cache the data of some frequently-used frames, e.g. the frames for "run" animation)
In our animations we're using Free-Form Deformation, so we have a lot of vertices and triangles. And rebuilding them each frame costs heavy. (we have a lot of spine animations in the scene)
Please help and let me know your suggestions. The biggest concern here is the performance.
Thank you!
There is a pretty substantial efficiency branch that hasn't been merged because it broke some existing features.
Beyond that, the renderer uses double buffering and a number of other things to save on performance.
I'm on my phone now but I'll write something a bit more comprehensive on this topic next week
- 수정됨
I think Mitch also has some numbers he can share in terms of "real world" performance.
He's been able to get hundreds of skeletons running on a device, I can't remember what.
You also have a bunch of other options for optimization depending on your use.
Frame limiting, update staggering, baking to native Unity animations to take advantage of GPU Skinning. Stuff like that.
This shouldn't be surprising though. If your game is simple enough, visual processing stuff will always be at the top of the list of things that are eating up cycles. It doesn't mean your game is slow, or that your game will unacceptably slow down even on 4 year old devices.
Thank you Mitch & Pharan!
Glad to know that this is being worked out and looking forward to it.
btw, how to "bake" the animation to native Unity animations? That sounds new to me. It will be so cool if Spine Editor can somehow output Free-Form Deformation into sprites on the atlas (which can avoid runtime deformation)
Baking converts the spine animations into unity animationclips. Unfortunately it doesn't support FFD.
If you want to render out sprite frames though you can so that through Spine itself in the export options.
Yeah, since Spine is more feature rich than the native Unity animation system and some things are arranged differently, Baking into native Unity animations causes some Spine features to be missing: FFD and animated attachment colors are a couple.
But Weights works (up to a number of bones) just like when you use skinned rigs in 3D programs. That's usually the more easily animatable option for deforming things anyway, while FFD catches edge cases
that is, when things look weird with skinning alone.