jabuwu
commented
4 months ago I think it wouldn't be a bad idea to ask the Spine devs to weigh in, as I'm sure they've encountered these same problems. They're super responsive to GH issues and forum posts and I'm sure they'd be happy to give guidance on what's doable. 🙂
For my own expertise, I've only spent time with the C runtime, which uses CPU skinning. The other engine integrations seem more complicated, especially the Unity one, and might be doing things a bit smarter.
I'm going to make a tracking issue here.
Currently, bevy spine's perf doesn't scale or leverage the advantages we'd expect from a skeletal animation system. These are all solvable, but may take some tinkering. (I'd like to work on some or all of this, but I have a move coming up so it might not be until after the summer).
Major things to address:
These changes should be possible without significantly changing the bevy_spine API.
I don't know if the underlying rusty_spine transpile is sufficient, but I'd guess that it is? Any spine_c based gpu skinning shader for spine on another engine platform would be an existence proof that these problems are solvable.
Instead of using the rusty_spine CPU skinning, we'd want to have a gpu buffer that contains the mesh instance information and a per-entity buffer that contains that entity's specific animation state (bone transforms, etc). rusty_spine should already contain this information.
The skinning shader itself would probably function similar to bevy's existing 3d animation skinning shader which is just some matrix math. I'm also assuming that Spine has mathy idiosyncrasies we'd need to extract from their software skinning implementation and duplicate in the shader code.