• Bugs

  • Mix-and-Match example has inconsistent control bones

    İngilizce

Hello, guys.
Browsing through the "mix-and-match" example from http://esotericsoftware.com/spine-examples-mix-and-match I found something strange that I believe I should share:

Repro steps:
1) Open the mix-and-match-pro.json as text
2) Find the "arm-front-up-3" bone in the skeleton bones json object
3) Notice that its X value is 132.36, also "arm-front-up-4" is using it as a parent. The 132.36 is incorrect offset, as it is from a non adjacent bone
4) Open the mix-and-match-pro.spine in Spine and select "arm-front-up-4", "arm-front-up-3" and "arm-front-up-2" in this sequence
5) Notice that their order is incorrect
6) Click the bones in the order defined in the "mix-and-match-pro.json" "arm-front" path constraint (which is the correct order):
"bones": [ "arm-front-up-2", "arm-front-up-6", "arm-front-up-5", "arm-front-up-4", "arm-front-up-3", "arm-front-up-7" ],
7) Notice that the order defined in the "path" is correct, while the one displayed in the Spriter graph (and in skeleton bones) is inconsistent

This means that unless the path constraint is applied, so the bones receive their positions in the correct order, the bones may appear incorrect in user application. Also their hierarchy is displayed incorrectly in Spine graph now.

In my opinion, the bones created for the control must always follow the same logic and their parent-child hierarchy must match the order in the path constraint, so the parent-child links in skeleton.bones will have them correct.

I also want to give the following suggestions:

  1. Add ability to move animation up/down in animation list. I were not able to do that despite moving animations in the .json file and importing it back
  2. Add ability to hide the Shear Transform for the ones like me that never use it, so the menu looks less messy and arrange better with the other tools
Related Discussions
...

  • Søren

  • Gönderi #3
  • Bu yayın İngilizce içinde

Hi,

2) Find the "arm-front-up-3" bone in the skeleton bones json object
3) Notice that its X value is 132.36, also "arm-front-up-4" is using it as a parent. The 132.36 is incorrect offset, as it is from a non adjacent bone
4) Open the mix-and-match-pro.spine in Spine and select "arm-front-up-4", "arm-front-up-3" and "arm-front-up-2" in this sequence

I'm not entirely sure what you mean by this? If you set Axes to Parent the x/y values shown for `arm-front-up-3 are identical.

4) Open the mix-and-match-pro.spine in Spine and select "arm-front-up-4", "arm-front-up-3" and "arm-front-up-2" in this sequence
5) Notice that their order is incorrect
6) Click the bones in the order defined in the "mix-and-match-pro.json" "arm-front" path constraint (which is the correct order):
"bones": [ "arm-front-up-2", "arm-front-up-6", "arm-front-up-5", "arm-front-up-4", "arm-front-up-3", "arm-front-up-7" ],
7) Notice that the order defined in the "path" is correct, while the one displayed in the Spriter graph (and in skeleton bones) is inconsistent

This means that unless the path constraint is applied, so the bones receive their positions in the correct order, the bones may appear incorrect in user application. Also their hierarchy is displayed incorrectly in Spine graph now.

In my opinion, the bones created for the control must always follow the same logic and their parent-child hierarchy must match the order in the path constraint, so the parent-child links in skeleton.bones will have them correct.

Items in the dopesheet are listed in the order they were selected, adding newest selected items on top. When you create a path constraint, the bones are ordered on the path constraint in the order they were selected. I don't see how this logic could be applied to the dopesheet.

1. Add ability to move animation up/down in animation list. I were not able to do that despite moving animations in the .json file and importing it back

We've added folders to animations recently, isn't this enough control?

2. Add ability to hide the Shear Transform for the ones like me that never use it, so the menu looks less messy and arrange better with the other tools

I'll bring this idea by Nate and see what he thinks. Personally I like it, but I love having options in general 😉

Hi, Sihu. Thanks a lot for your answer.

Shiu yazdı

Items in the dopesheet are listed in the order they were selected, adding newest selected items on top. When you create a path constraint, the bones are ordered on the path constraint in the order they were selected. I don't see how this logic could be applied to the dopesheet.

Ah, I didnt know that. I guessed they would follow the order from skeleton bones hierarchy, so parent will always be before its child in the constraint.
[quote="Shiu"]We've added folders to animations recently, isn't this enough control?[/quote]
Im not at my PC now, so I cannot check, but folders are nice for organizing stuff in general. Like to have "Cinematic Anims" folder for example. But inside you may have "Level_02_cinematic", "Level_18_cinematic", "Level_01_cinematic", just because the animator doing the animations added "Level_02_cinematic" first. If by adding/removing the animations inside the folder we can arrange the order so that for example the animations follow some order meaningful for us, it still may do. Also, we may have a few animations and not use a folder, but we want to arrange them so they are like: "idle, walk, run, jump, attack" and the least used animations to go after them this will be the ideal control. Later on, if animations are called by name this may improve the traversal time a bit, not to mention that animations will be organized better, with freedom at its best. Drag-and-drop or up-and-down arrows in the anims list will do.

Again, thanks for your time. =)