@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:
- Inactive bones (of all inactive directions) might be updated unnecessarily.
- The same animations might need to be applied at multiple skeleton GameObjects.
- 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.