warmanw I'm not sure if this will be helpful, but I will describe my experience: I have rigged a character that changes direction to face forward, sideways, and backward in a single skeleton. The reason I had to create the character in a single skeleton at that time was because the client wanted the character to be able to change direction smoothly. So it also required creating some transition animations for changing direction. If the skeleton had been separated for each direction, creating them would have been very difficult to create. I think that is the key to whether or not skeletons should be separated when creating a character that faces multiple directions. In other words, you should consider whether or not there is a possibility to have multiple directions in one animation. For example, a character who attacks with a sword may swing the sword with the lower body facing sideways and the upper body facing backward, and then the upper body turns sideways and the character strikes a pose in which he has finished swinging the sword. If your character does not match the case, I think it would be easier to manage (control) that creating multiple skeletons for it (the method you are taking now) than rig all directions in a single skeleton.

I feel I have written something obvious, but I hope it will be of some help.

@warmanw Sorry for the late reply. Which version would be better performance-wise depends.

Let's define the unnecessary overhead that may occur in general:

1. Inactive bones (of all inactive directions) might be updated unnecessarily.
2. The same animations might need to be applied at multiple skeleton GameObjects.
3. GameObjects and additional attached components have some update overhead.

Single skeleton (instead of one for each direction):
If you use a single skeleton, you will have many inactive bones (which don't move in the active Animation), so you will have some unnecessary bone-update-overhead there (overhead 1). On the positive side, you only apply animations once and don't have additional GameObjects or components (no overheads 2 and 3).

Separate skeleton for each direction:
Here it depends on whether you can disable GameObjects of inactive directions and only call an animation on the active direction's skeleton (a), or need to keep them in sync in terms of animation-state (b).

• a) If you can disable the GameObjects of inactive direction skeletons, and only ever set animations at the active skeleton, you save all unnecessary overheads above. The drawback of this method is however that when switching directions during an animation, it requires some additional code to not start animations from time 0 again, but instead continue where the other direction left off. So it involves more programming work to get it right, and might be more error-prone.

• b) If you need to call the same animations at all directional skeleton GameObjects (if you need to keep them in sync), you will have the same inactive-bone-overhead, plus duplicate animations to be applied, plus some GameObject-related overhead (so all overheads 1, 2, 3). This would therefore have the highest overhead of all options.

Regarding rendering, all options should be equal since no disabled attachments will be rendered (added to the mesh), and the resulting total number of vertices is the same.

@warmanw You're very welcome, glad it helped! Looking forward to the tutorial, thanks for all your work!

Thanks for sharing!

A very interesting setup indeed. Got me thinking how the process could maybe be simplified with a few additions to Spine. Still far too early to get into anything concrete though.

Selection sets with more customization would definitely be a helpful tool for this workflow

@warmanw Awesome, thanks for sharing!