To address your issue of CPU bottlenecking with multiple Spine2D animated monsters in Unity, you can consider a few strategies to reduce the CPU load:

1. Disable SkeletonAnimation Component: You can disable the SkeletonAnimation component to stop the animation updates and mesh regeneration. This will save CPU resources as the animations won't be processed. However, this might also stop the events from firing, which you need for remote procedure calls.

2. Custom Culling: Implement custom culling logic to disable GameObjects when they are not needed, such as when they are off-screen. This prevents unnecessary updates and rendering, reducing CPU usage.

3. Use Fixed Timestep Updates: Consider updating the skeletons at a fixed timestep rather than every frame. This can be done using the SkeletonAnimationFixedTimestep component, which allows you to control the update frequency.

4. Optimize Skeleton Complexity: Reduce the number of bones and vertices in your skeletons. Fewer bones and vertices mean less computation for the CPU. You can also prune unnecessary weights and simplify the skeleton structure.

5. Separate Logic and Animation: If possible, separate the logic that handles events from the animation. You might be able to create a lightweight system that only processes the necessary events without involving the full animation system.

6. Pooling and Reuse: Use object pooling to manage your monsters efficiently. This can help reduce the overhead of creating and destroying GameObjects frequently.

By implementing these strategies, you should be able to reduce the CPU load and handle more concurrent instances of animated monsters in your game.

JohnSully My game server needs to have about minimum 1000 concurrent instances of Spine2D animated monsters roaming the world.

Why does your server handle animation? This makes no sense, as you would also need to sync the detailed animation state of the characters with each client. Your server should handle game logic and physics, in other words game state of each character, not animating them in detail and taking over work that the client needs to do.

If you really need to run animations on the server, you should set SkeletonAnimation.UpdateMode to e.g. UpdateMode.OnlyEventTimelines accordingly to just process event timelines.

@JohnSully Glad to hear it's helpful, thanks for the detailed writeup.

If you need to strip away more AnimationState timeline processing, which I have a feeling should not be performed on a server at all, you could alternatively extract the event timepoints via a Unity Editor script from the SkeletonData, and then just store the time offsets from when the animation starts. Then you could just store and process character state and issue events at certain offsets after entering a specific character state instead of after starting certain animations.

JohnSully Does this mean that we'll need to write an editor script to extract that information from the .json file?

A side note: as listed here, for production use you should in general be exporting as binary .skel.bytes format instead of as .json. This is because binary format loads faster and is smaller in size.

Regarding your actual question:
I did not mean that you should be parsing the .json file yourself. Instead you should be getting the SkeletonData (note that I wrote SkeletonData, not SkeletonDataAsset) in your editor script. You can access it from SkeletonAnimation via skeletonAnimation.Skeleton.Data. Alternatively you can access it via the SkeletonDataAsset through skeletonAnimation.SkeletonDataAsset.GetSkeletonData(true).

Then you can access SkeletonData.Animations and at each animation access Animation.Timelines, and if (timeline is EventTimeline) you can cast it and access the timepoints and events accordingly. See AnimationState.ApplyEventTimelinesOnly as a reference.

JohnSully Or is there a way to extract it directly from the SkeletonDataAsset file like you suggested?

The SkeletonDataAsset only holds references to the text assets which are then parsed. You should let the spine-unity runtime perform the general loading, and then access the loaded information as described above.