• Editor
  • 8-way movement with one skeleton

Related Discussions
...

I’m working on a spine character for an isometric game with 8-way movement that allows controlling the viewing direction of he upper body independently from the direction oft he legs. So you can walk north while looking or shooting east.

One way to achieve this was to set up a simple skeleton with different skins for the upper and lower body for all directions. Then I created animations just for the legs and other just for the upper body. Later, they can be set on different tracks in the runtime. It works, but you need to set a lot of keyframes for each animation to keep the skeleton in line with the current direction.

In another setup, I created one large skeleton that has separate bones: Each direction has its own upper and lower body bones, but they all share one single hip bone. In total, this skeleton uses 136+ bones and 32 IK constraints.

In this complex skeleton, lots of bones need to be calculated in runtime, although just a few oft hem will be visible in the current combination of leg and upper body direction.

I would like to ask for your feedback on these two methods.

What do you think about them?

Would it be possible and make sense to skip the currently irrelevant bones in runtime?

Is there a meaningful way to use transform constraints to freeze bones of the inactive directions?

I use a single skeleton with 4 way movement

Image supprimée en raison de l'absence de support de HTTPS. | Afficher quand même

I use the first method you mentioned and it works well!

I vote separate skeletons, just for the sake of the sanity of the animator, and less wasteful animations. (This is the better alternative compared to your second option)

But for some cases, your first option and having one skeleton makes sense, especially if you don't have a lot of bones and your style is very forgiving of alignments.

It’s good to see the first method is working well in a game that seems to be near completion. Nice!

I think in my case 8 separate skeletons are not an option, since I want to be able to combine any upper body direction with any lower body direction -> legs walk south, upper body facing east. (‘Classic’ strafing movements turned out to look strange.)

To get the best of both methods I came up with the pseudo-separated skeleton. The workflow in spine is better than all directions using the same bones.

The doubts remaining concern runtime performance. About 120 bones are irrelevant to the currently displayed combo of directions each frame.
So we thought to create a filter in the bone calculation function, updating just the bones of the current combo of directions.

Do you think it might work?
Or is there something we are losing sight of in this approach?