- Modifié
Layering Multiple Skeletons at Runtime
We are currently working on a game that will require us to be able to swap out Legs, Torso, Face, Hair, and Hats at runtime. We are currently using the Mix and Match method of swapping images on the character as we plan to continue to add content to the game at a scale that would make Spine Skins unmanageble.
The Mix and Match functionality works great, but at the same time appears to limit us in adding slight variations to some of the elements above without adding numerous bones to the base rig that won't be used most of the time. For example, we have one hat that has a feather on it that we would like to have some animated bounce. My understanding is that to add this functionality we would need to add a bone in our base rig for that feather to animate, and then with any other hats there will always be a vestigal bone left in the rig animating that doesn't do anything. Another example would be different hairstyles that deform in different ways.
I was thinking that a potential work-around would be to export each of these elements (Legs, Torso, Face, Hair, and Hats) seperately from Spine, and then re-combine them under a Parent object in Unity. In theory this would allow us to create "variants" of the Hat's rig and sub in one of those variants as needed... but then we run into the issue of sorting between multiple SpineSkeletonRenderers. Using the SkeletonRenderSeparator would probably work for something like a Hat that only has one layer, but with how I understand the implementation we would run into issues with elements like Hair that need to layer both in front and behind the character's Head. Is there any way to layer multiple skeletons within Unity that would still observe each skeletons sorting depths? Would there be a more effective way to accomplish this level of modularity IN Spine?
PBChris a écritFor example, we have one hat that has a feather on it that we would like to have some animated bounce. My understanding is that to add this functionality we would need to add a bone in our base rig for that feather to animate, and then with any other hats there will always be a vestigal bone left in the rig animating that doesn't do anything.
That's what skin bones are for, see the following documentation section:
Skins - Spine User Guide: Skin bones
PBChris a écrit[..] but with how I understand the implementation we would run into issues with elements like Hair that need to layer both in front and behind the character's Head. Is there any way to layer multiple skeletons within Unity that would still observe each skeletons sorting depths? Would there be a more effective way to accomplish this level of modularity IN Spine?
I'm afraid I don't quite understand why you see a problem here. Normal Mesh sorting rules apply here, SkeletonRenderer
just fills a MeshRenderer
and MeshFilter
with data. If you place a second Mesh GameObject in front of it and a third one behind, then it will render multiple mesh GameObjects just as it normally would, respecting your camera's sorting settings. Or did you mean something different?
PBChris a écritWould there be a more effective way to accomplish this level of modularity IN Spine?
I would still recommend using Spine skins here. If you really intend to create a vast number of different hairstyles and don't want to create separate skins for each and re-export the skeleton, you can still go with one generic skeleton that is basically covering all types and then separately export atlases and load the content from these atlases at runtime. In general I would not recommend layering multiple MeshRenderer
objects if it can be avoided, just for keeping the draw call count low.
If you place a second Mesh GameObject in front of it and a third one behind, then it will render multiple mesh GameObjects just as it normally would, respecting your camera's sorting settings. Or did you mean something different?
Sorry if it was unclear, what I actually meant was if there was a way to have 2 seperate Skeleton Renderers that sort with eachother based on the slot order within their Spine files, though I dont know how they would even have that information to do so. It sounds like thats not a thing regardless.
It seems like using the skin bones would be the easiest way to technically work with our situation, unfortunately we are looking at upwards of 100s of variations so I would forsee that master Spine file becoming very heavy and difficult to work with.
We aren't sure of the specifics of all the variations we will need... but it sounds like figuring that out ASAP and including as many reusable bones in that master rig is the way to go, rather than trying to combine multiple renderers in Unity.
Thank you for the reply! All that info is very helpful.
PBChris a écritSorry if it was unclear, what I actually meant was if there was a way to have 2 seperate Skeleton Renderers that sort with eachother based on the slot order within their Spine files, though I dont know how they would even have that information to do so. It sounds like thats not a thing regardless.
Thanks for the clarification, now I understand what you meant. Unfortunately a MeshRenderer
will always draw an entire mesh in a draw call, so there is no way to interleave two MeshRenderer
meshes other than splitting them into parts. That is without using the Z-Buffer of course, which is not a good option for transparency unfortunately. The spine-unity runtime provides the SkeletonRenderSeparator component for this reason to split one mesh into multiple.
PBChris a écritIt seems like using the skin bones would be the easiest way to technically work with our situation, unfortunately we are looking at upwards of 100s of variations so I would forsee that master Spine file becoming very heavy and difficult to work with.
You may want to break down the setup into groups of similar items, like hats with feathers, hats with wiggly horns, Santa-Claus-like night cap hats, and so on, and prepare the universal bone and attachment structure once. Each of these hat-groups would then be a skin with a set of skin bones. Then you don't necessarily need to create the hundreds of skins in Spine (though they could be hidden away in folders without cluttering the project), but could instead have each new hat (e.g. red-hat-with-blue-feather
) create a copy of the best-suited hat-group skin (feathered-hat
) and replace the skin's attachments with the needed attachment assets (a red hat image and a blue feather image). Nevertheless, it might still be more comfortable to add all 100 hats as hat skins in the Spine project and hide them away in folders.
PBChris a écritWe aren't sure of the specifics of all the variations we will need... but it sounds like figuring that out ASAP and including as many reusable bones in that master rig is the way to go, rather than trying to combine multiple renderers in Unity.
This definitely sounds like a good idea, the earlier the better. We also strongly suggest speaking with artists and programmers alike, trying out the workflows, and testing how everyday work collaboration should happen.
It's definitely possible to do hundreds of skins for this sort of thing. We're doing that on our project (four spritesheets and counting so far) and it still performs well. Organization is the real problem. Use a good naming system and file structure.
I have been thinking for a while about cutting some parts out into a separate skeleton, though. For some FX related things. Just haven't put in the time to figure it out yet. Maybe with the SkeletonRenderSeparator. Researching that is going on my todo list.
(of course SkeletonAttachment would make this super easy wink wink nudge)
Thanks very much for sharing your experience @refractedthought, much appreciated!
refractedthought a écrit(of course SkeletonAttachment would make this super easy wink wink nudge)
Your voice has been heard.
In general the SkeletonRenderSeparator
component should be similarly easy to use as a SkeletonAttachment
component, you just set the separation Slot where you want to insert (attach) your GameObjects at, then you can place as many GameObjects with a BoneFollower
component each as you need.