Unless that's wishful thinking on my part and he's just adding it to each 4.x milestone list as a cruel joke, which I doubt.
I'm afraid it's not a cruel joke, but simply due to that work being quite a bit more than 1 month of one devs time. It's also non-trivial, as the data layout needed for DOTS is so far away from what we actually have (and need), that it constitutes a complete rewrite of the Spine Unity Runtime. All of that, while the "old" system needs to keep working and gets bug fixed and updated for new Spine features. I understand that's frustrating, but it's a function of our team size paired with what most of our users need. Displaying hundreds of complex skeletons on screen at the same time is not generally a use case many of our users have.
Those appear to be rather heavy to be honest. Here are Spineboy's metrics a rather complex sample character that comes with Spine.
Note that Spineboy is a character that takes up a lot of the screen, e.g. in a platformer, so he has tons of detail to pop out of the display. All your walkers have more vertices and triangles than him, which is what will dictate your computational requirements.
Now, you say you are displaying hundreds of walkers on screen at once. That would mean, you have a very zoomed out view, in which case your walkers will not take up a lot of screen space. Chances are, all that detail your artists are baking in will get lost in the zoom. Like here:
Even in 4k, there's simply no way to see all that detail your skeletons have.
Here are a few proposals:
- Cut down on the number of vertices in your meshes, and if possible, use regions (rectangles) instead of meshes where possible. At this detail level, you can get pretty much the exact same look if you use shear in addition to translation, scale, rotation. I know that going back in and modifying those skeletons can be quite a bit of work, but it will definitely pay off. If you share one of the skeletons with us, we can possibly give you tips on how to best approach this (either here or via contact@esotericsoftware.com).
- I assume you do cull walkers outside the viewport? If so, simply disable their animation updates while they aren't in view. The underlying AnimationState is stateless, so it suffices to keep track of the animation delta time until the character is in view again, and only then do a full update of the animation state and skeleton.
- If too many skeletons are displayed at once at a time, you can opt to update their animation state only ever other frame. E.g. half the skeletons get updated on odd frames, the other half gets updated on even frames. That will effectively cut down the processing time in half, and is what you usually do for things like path finding as well. Again, the scale plays to your advantage, as the effective halfing of the animation framerate is unlikely to get noticed. You may also only opt to do this if too many skeletons are on screen.
The remake is targeting desktop machines, so you may actually get away with not doing any of the above, especially modifying the skeletons and animations themselves. However, a few items are quick wins and likely quite easy to implement without a degradation of your game's quality.
The Spine Unity Runtimes support baking, but it has limits requiring you to rework your animations/skeletons and may actually not give you a huge performance boost in return: spine-unity Runtime Documentation: Skeleton Baking
The remake looks dope btw!
