PBChris a écrit

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.

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 écrit

Would 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.

PBChris a écrit

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.

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 écrit

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.

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 écrit

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.

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)