How to optimize performance uses a large number of Spine objects?

nibya

Hello,

I’m currently developing monsters and player characters using visually appealing Spine animations for a game inspired by Vampire Survivors.

Due to the nature of the genre, one of the most critical elements is the satisfaction of defeating large numbers of enemies. To achieve this, we need to spawn a substantial number of game objects, and are therefore conducting stress tests to determine how many can be handled simultaneously.

Our current target is to maintain a stable 60 FPS with 600 monsters on screen during basic combat scenarios. However, profiling has shown that the more Spine objects we create, the heavier the processing load becomes during the Update and LateUpdate phases.

In our stress test environment, only basic features such as player tracking and attacks using Rigidbody and Collider are active. Despite this, the build currently runs at around 40 FPS. We expect further performance demands as we continue developing new skills and adding projectile mechanics for monsters.

Currently, Physics 2D accounts for about 30% of the load, and we’re actively working on optimizing that. And, we’ve also observed that SkeletonAnimation's Update and LateUpdate combined take up roughly 40%, so we thought need to optimize this also.

I would like to ask if there are any recommended strategies or best practices for optimizing Spine's runtime performance—especially regarding SkeletonAnimation's Update and LateUpdate—to improve our overall performance.

Thank you for your time and support.

Misaki

nibya I believe our Unity expert, Harald, will provide a more detailed response later. In the meantime, if you haven't already, please check out the "Performance" section of the spine-unity FAQ. It summarizes general points to check for performance improvements and should serve as a useful guideline:
https://esotericsoftware.com/spine-unity-faq#Performance

Spinebot

To optimize the performance of a large number of Spine objects, consider the following strategies:

Binary Export: Use binary export (.skel.bytes) instead of JSON for your skeletons to reduce loading times and memory usage.
Object Pooling: Implement object pooling to manage your Spine objects. Pre-load a pool of objects and reuse them instead of instantiating and destroying them during gameplay.
Culling: Configure your Skeleton components to update only when visible. This can be done by adjusting the "Update When Invisible" setting.
Reduce Clipping: Avoid using clipping polygons as they have a high impact on performance. Use Unity's masking features like Mask, RectMask2D, or SpriteMask instead.
Optimize Skeletons: Prune unnecessary weights, remove vertices with identical weights, and deactivate non-visible attachments when clipping is active.
Fixed Timestep Updates: Consider updating your animations every N frames instead of every frame to reduce the load.

These optimizations should help improve the performance of your game, especially when handling a large number of Spine objects.

nibya

Misaki

Thank you for sharing the information.

We have reviewed the guidelines and believe that we have followed them accordingly.
Additionally, we have attached the Spine file.

Based on information gathered from the forum, we also set the Update When Invisible field of the SkeletonAnimation component to Nothing, and enabled both Immutable Triangles and Clear State On Disable.

Please let us know if any further information is needed.

spine.zip

94kB

Harald

@nibya Misaki and Spinebot already listed the most important points. In addition to that, you might want to consider the following:

RenderExistingMesh:. Given that your mosters likely look and move in a very similar way, instead of updating every Nth frame, you could also use the RenderExistingMesh component to copy the already animated mesh of another skeleton, saving both the Update and LateUpdate cost. This might be quite feasible if you have e.g. 20 instances of the same skeleton type just playing a move-animation, you then might get by having only 3 - 5 different truly animated skeletons and let the rest be copies of the original ones via RenderExistingMesh. This should bring quite a dramatic improvement on lowering the LateUpdate and Update cost.
Parallelization / Threading: This feature ticket (currently in progress) will cover providing automatic parallelization infrastructure where you can utilize multiple threads with your skeleton components at the switch of an option. While it's not completed and released yet, the implementation is almost done, some cleanup and consolidation is still in progress. This will be a really handy "free" optimization.

Apart from that, let me emphasize again that optimizing the bullet points mentioned by Misaki and Spinebot (keeping the metrics as efficient as possible) will pay off a lot.

nibya

Harald

Thank you for your response.

Regarding point 1, it seems applicable for basic-type monsters, so we believe it can be implemented in those cases. However, as the difficulty increases, more monsters will have unique behavior patterns that are closely tied to their animations, so it may be difficult to apply universally. That said, it would still have a meaningful impact.

As for point 2, I’m also very interested and have already subscribed to the related issue. I'm truly looking forward to it and hope to see great results.

In the end, we hadn’t yet tried point 6 mentioned by Spinebot, but we successfully customized the update cycle accordingly.

However, while this reduced the load from the SkeletonAnimation.Update logic, the LateUpdate still imposes a significant performance cost. We understand this is due to the structural limitations of the SkeletonRenderer component.

Ideally, further development toward enabling parallel processing would be the most effective solution.
Since there’s still plenty of time before our game’s release, we’ll continue to monitor the situation closely.

We look forward to hearing good news!

Harald

nibya In the end, we hadn’t yet tried point 6 mentioned by Spinebot, but we successfully customized the update cycle accordingly.

However, while this reduced the load from the SkeletonAnimation.Update logic, the LateUpdate still imposes a significant performance cost. We understand this is due to the structural limitations of the SkeletonRenderer component.

Why would LateUpdate, which covers updating the mesh, impose a significant cost? If it does, you likely have misconfigured your setup. See the Other Examples/FixedTimestepUpdates example scene, component SkeletonAnimationFixedTimestep.