How to optimize when using many spine objects

UnitySerializer

Hello, I'm a Unity 3D client developer working on a 2D project using Spine.
I have some optimization questions.
Since English isn't my native language, I'm sure there are grammatical errors.

[Testing OS]
Mac M4 Max

I'm making a game that requires a lot of spine objects inside the game view.

It's a call that goes back through the Unity event, but since I downloaded it as a Git Package, it doesn't really matter.

However, I want to optimize the animations as well as the batches to use the corresponding number. In order to defend 60 frames as a basic feature, I used multi-threading for various actions such as pathfinding, but even in idle state, it takes up more than 10ms in Spine, so I have a hard time defending 16ms (60 frames).

Especially since the game behaves similarly to a top view, the movement animations are all different vertices, which is a bit of a hassle.

Since I am not familiar with Spine, I followed the manual as much as possible to set the basic options for the components, and additionally asked the designer who works on Spine to make it Binary instead of Json.

I've managed to batch a lot of these objects, but I haven't really touched the mesh part that seems to update or regenerate internally. For that game mode, I want to optimize Spine as much as possible.

Additional

Previously, physics were applied to the cat's tail.
This caused freezing when all 32 cats transitioned into their movement animations.
We've compromised by not using physics.
(If you have a solution for this, please let me know.)

I would really appreciate it if you could answer.

Spinebot

Based on your situation with many Spine objects causing performance issues, here are several optimization strategies you can implement:

Key Optimization Techniques:

Use RenderExistingMesh for Duplicate Skeletons
Since you have multiple instances of the same cat skeleton playing similar animations, you can significantly reduce CPU cost by using the RenderExistingMesh component. This allows you to have only a few "master" skeletons that are fully animated, while the rest copy their mesh data without running Update and LateUpdate.

For example, with 32 cats, you could have only 3-5 fully animated skeletons and let the remaining 27-29 cats copy the mesh from these masters using RenderExistingMesh. This should provide substantial performance improvements.
Enable Threaded Mesh Generation
In your component's Inspector under Advanced, enable Threaded Mesh Generation. You can also set the global default in Edit - Preferences - Spine - Threading Defaults - Threaded Mesh Generation. This offloads mesh generation to worker threads.
Enable Threaded Animation
Similarly, enable Threaded Animation at your SkeletonAnimation components or set it globally in Spine Preferences. This moves animation updates to worker threads.
Atlas and Material Optimization
- Ensure all cats use a single atlas texture to minimize draw calls and material switches
- Verify you're using only one material per skeleton
- Check the Performance FAQ section for material-related optimizations
Reduce Animation Complexity
Work with your Spine designer to:
- Minimize mesh deformation keys
- Use as few vertices as possible in meshes
- Remove unnecessary animation keys
- Optimize metrics shown in Spine Editor's Metrics view
- Avoid clipping attachments if possible
Update Frequency Optimization
If some cats are far from the camera or less important, consider updating them less frequently using UpdateFrequency settings on the SkeletonAnimation component.

Regarding Physics on Tails:

Physics constraints are indeed expensive when used on many skeletons simultaneously. Your compromise to disable them was correct. If you absolutely need physics effects:

Only enable physics on the closest/most visible cats
Consider using simpler bone-based tail animation instead of physics constraints
Use the RenderExistingMesh approach so only a few "master" cats actually calculate physics

Additional Resources:

For comprehensive performance optimization guidance, review:

Performance FAQ
Spine Unity Assets - Performance considerations

The combination of RenderExistingMesh for duplicate instances and threaded processing should significantly reduce your 10ms overhead. Start with these changes and measure the impact before implementing more complex optimizations.

UnitySerializer

If my understanding of RenderExistingMesh is correct, if I create 7 root cats for each animation that is playing the animation in advance and set them to follow the appropriate root when the animation changes, would I get better performance?

Harald

UnitySerializer Please note that spine-unity 4.3-beta just recently received a threading implementation, mentioned by Spinebot as well, which you can enable, which should help a lot.

UnitySerializer If my understanding of RenderExistingMesh is correct, if I create 7 root cats for each animation that is playing the animation in advance and set them to follow the appropriate root when the animation changes, would I get better performance?

Yes, if you skip the SkeletonAnimation.Update and SkeletonAnimation.LateUpdate calls of 90% of your skeletons completely and just re-use an already existing output mesh, you will save a lot.

UnitySerializer

Harald

I've seen a lot of performance improvements using Multi-Threading and RenderExistingMesh in 4.3beta.

I have a question: Is there a way to change skins when using RenderExistingMesh? Do I need to use a material property block? I only have one atlas.

UnitySerializer

That is, I want to copy only the animation of the cat as the root mesh and material, and then modify each RenderExistingMesh part to make it have its own skin (color).