- تم التحرير
How to have swappable heads *and* skins?
Hiya ... we've been using Spine to animate all the characters in Rogue Wizards (http://www.roguewizards.com) for over a year now and absolutely love it.
We're using the skins feature for the human player and NPCs to create different looks for the body that swap out all the images for light, medium, and heavy armor looks. We're also using images that are under regular slots (not skin placeholders) to do attachments that are visible during all skin looks and things are working great.
However, what we would like to do now is also have the ability for one of these humans to have many different fully animated heads which can be used in any of the light, medium, or heavy body armor looks governed by the current skin.
The only way I can think to do this is to create different bone/slot hierarchies for each of the heads (say Head01, Head02, etc) and show/hide those entire hierarchies via code. This has a couple of disadvantages that come to mind though:
1) There doesn't seem to be a great way to turn on/off a head hierarchy in the editor in order to animate just one head, and toggling the slot visibility of all needed nodes in setup mode seems difficult and problematic
2) The hidden heads and all their bones are probably still animated in the background taking up unnecessary processing time
Perhaps another method would be to build the matrix of skins for all head and armor combinations ... but that seems hard too.
Any ideas on the best way to accomplish this kind of setup?
Do all your heads use the same bones? Or close to it? Eg, maybe there are only a few bones that some heads don't use, but most heads use all the bones. If that is true, then you can solve the issue by creating a new skin at runtime and populating it with the attachments you want to use. This way your generated skin can have the attachments for heavy body armor plus the attachments for whatever head you like. One way to do this is to still use skins, but only for parts of the skeleton. Eg, you'd have a "heavy body armor" skin and a "head3" skin. At runtime you'd grab all the attachments from both of those skins and stick them in a new skin that you set on the skeleton.
Hi Nate,
That seems like a good approach to keeping the runtime clean ... but I don't think solves the workflow issue within the editor to animate all the heads.
Let's just say that the heads have all the same bones for simplicity, which is not the case as some have long hair etc but ok. For each new head, in the editor my animator will want to be able to see the head along side the light, medium, and heavy armor looks to make sure each of the 30 head animations look good in each of the 3 body skins ... but I don't think there is a way to show the attachments in the editor for "Heavy Body Armor" skin and "Head 03" skin at the same even if their attachments are mutually exclusive is there?
Put another way ... a clean "Head 03" skin wouldn't have any images for body parts, and "Heavy Body Armor" skin wouldn't have any images for any heads ... and the editor wouldn't be able to display these things at the same time so I'm not sure how my animator should approach animating them.
This is what was leading me down the road of duplicating the head bone hierarchy for each head and animating it separately ... but even with that idea I'm not sure what the best way would be for my animator to turn on/off the heads they need to see for each animation and body armor skin combination.
Still searching for a solution, so ideas are welcome.
Right, the editor can't display multiple skins at once. To do this there has to be some way to denote the current skin, so manipulating skin placeholders will only affect that skin. Likely this will be done with a "Skins" view.
Until then you could duplicate a head skin, add the armor attachments, then delete the head attachments. Or duplicate an armor skin, add the head attachments, then delete the armor attachments. Or maybe better, you could leave the head in the armor skin and the armor in the head skin, then have code at runtime that knows to ignore those attachments for the purposes of combining skins. It's not ideal, but I think having lots of head bones isn't great either.
Another way to solve this in the future would be to have the heads as separate skeletons, then Spine needs to support a "skeleton attachment". You body skeleton would have "head" slot where you can attach any of the head skeletons. spine-libgdx supports a skeleton attachment at runtime, but the UI is not yet complete in the editor. This was very easy to implement in libgdx, but may be more difficult in other runtimes.
Delver's Drop has been doing this with Spine for a long time. They have separate body and head skeletons and they draw the head on top of the body at runtime. This way you don't have extra bones. It does mean the head skeleton has to be fully on top or behind the body though.
2 أشهر لاحقا
Finally getting back to this. First let me respond to Nate's latest brainstorms.
1) Duplicating the skin and animating each head. This will work allow for my animator to see both the body and head while animating which is good. Deleting those duplicated bones after animating would be good but it would make coming back and adding/tweaking animations difficult since the body is no longer there. Leaving the bones in and building a runtime skin seems like it would leave a ton of bones.
2) Love the skeleton attachment idea, unfortunately our heads aren't just on top of bodies and are under some attachments and over others.
Brainstorming some more here ... I thought I'd see if I could hack some stuff, so I tried on setup iterating all slots and setting all attachments to null if that attachment was under head bone hierarchy I didn't want. Then I set added a "disabled" bool in the attachment setter so that no further attachment values could be assigned. As far as the runtime this is giving me what I want by essentially "hiding" all other head attachment hierarchies except the one I want.
This has some downsides though, and I'm wondering if you might have any suggestions
1) Down low "disabling" attachment functionality on slots seems dirty to me ... is there a better way?
2) It leaves the bones and slots for all the other head hierarchies in tact and presumably animating in the background. Is it possible to actually remove/delete entire bones and/or slots during a setup phase of the runtime? If so, can you point me in the right data structure direction (Unity C#)?
3) Animating in the editor is less than ideal because my animator wants to look at one head hierarchy at a time in order to animate it, and there isn't a way to quickly turn on/off the visibility an entire hierarchy without first expanding every node and clicking the visibility of each slot. The fastest way I found to do this was show bones+slots, and then multiselect using shift and toggling the visibility dot. Please let me know if there is a faster way.
Also, open to other approaches.
Thanks for your time Nate!
Let me just say, thanks for putting this out there.
I don't think the Spine editor currently handles this very well and it's valuable input for Nate and Shiu to know about these cases. I'll be needing similar functionality soon and it's cool that you've posted some concrete, farther-along-the-way stuff before me. XD
2) There were two separate but slightly interrelated collections. The Bone collection is currently a tree (the head of the tree is the root bone). The Slots list is a linear list. Each slot relies on a bone for when it's rendered. But the bones don't have any knowledge of what slots are under it. The bone collection has also become a bit more complicated since I last checked it. It seems that Skeleton now holds a few more representations of the Bones collection as a List and as a separate "cache". This seems to be optimizations for IK.
Anyway, removing bones means you have to remove them in 3 different places or something? It also involves making sure you clean up the slots under those bones (which is some extra work because, again, Bones themselves don't know what slots they have. you have to ask the Skeleton for that. It's not that hard though.) Otherwise, you'd have slots that get rendered weirdly because they're still referencing Bones that aren't being actively updated and on the Skeleton anymore. This is the funny situation where removing the bones from those collections won't clean them up because the Slots still have references to them.
The bad thing is that if you rely on slot attachment animations or animated DrawOrder, tampering with the Slot list will break those things because they rely on their position in the list/array to work properly.
3) This is pretty close to the use case I'm looking for and I think Nate's answer is SkeletonAttachments, which isn't here yet, and should take a bit longer because he's still working on Spine 3.0 (the new scale inheritance and flip systems). From what I know right now, there is no faster/cleaner way.
Sorry, I don't actually have concrete help.
ohh! But on the earlier concern. Since you're using Spine-Unity, a separate head skeleton would not need to be complete behind or in front of the body skeleton. It would be doable right now (albeit a bit of extra effort to coordinate animations), and it would be portable when Spine eventually has official support for SkeletonAttachments.
Right now, Spine-Unity effectively has (not previewable and animatable in Spine editor) SkeletonAttachments and you can insert things, any Unity GameObject (including another Spine SkeletonAnimation GameObject) into the rendering. Look up SubmeshRenderer and Submesh Separators. That's what you want if you want to go that route.