Skeleton3D has bone indexes unpredictably shuffled around when importing GLTF

[antourenein]

Godot version

4.0 alpha 9

System information

Windows 10, Vulkan, NVIDIA GTX 850M

Issue description

Every time a new GLTF scene containing a complex character skeleton is exported from Blender and then imported into Godot, the bone indexes are shuffled around and cause unpredictable animation and skeleton modification behaviors, requiring me to manually re-add the model to the player scene and change the modified bone indexes in the SkeletonModificationStack3D in order to fix the problems.

Note 1: This happens even if I do not modify anything in the Blender scene. I just need to export to a new glb file and Godot shuffles the indexes and ordering around when importing. The imported scene may stay the same if I re-export it in the same Blender session, but if I just close Blender, open it again and then try to re-export the scene, it is already unpredictable.

Note 2: This does not happen in the 3.x branch of Godot. The bone indexes and ordering are preserved as expected.

How the scene cointaning the model looks when everything is in place:

Godot_v4.0-alpha9_win64_YioWlQkj0C.mp4

How the scene containing the model looks after just closing and opening Blender and re-exporting the model without any modifications in the blender scene:

Godot_v4.0-alpha9_win64_egxaRG3UNP.mp4

(This is random, I never know what kind of crazy shape the character will take in the next export)

Steps to reproduce

Create a character with a complex armature in Blender (in this case, I used rigify and only exported deformation bones), export it to glb, add the model to a scene and set up the scene. Then try closing Blender, opening it again, and re-exporting the character to the same file and watch the scene that contains the model break with bone ordering issues.

Minimal reproduction project

No response

[fire]

Can you provide any type of example project that demonstrates this? It worked in our test cases https://github.com/godotengine/godot-tests/tree/master/tests/gltf_skeleton_tests when we were developing this.

[fire]

Also, can you try specifically Blender 3.2, the unreleased version?

[TokageItLab]

I think this is a problem with Blender's glTF exporter. Can you post glTF diffs?

[antourenein]

Also, can you try specifically Blender 3.2, the unreleased version?

It seems exporting from this version does keep the bone indexes stable and essentially fixes the problem... although it has created its own set of problems, such as some bones being strangely twisted.

I wonder if that is something I have to fix myself in the scene. I'll investigate further when I have some more time.

[fire]

Please try to contact the gltf blender team. https://github.com/KhronosGroup/glTF-Blender-IO/issues @julienduroure

[antourenein]

Upon further inspection and testing, it seems Blender 3.2 is in fact twisting the bones strangely on export, it even gets twisted when re-importing the GLB into Blender. I'll try to open an issue over there.

However I still find it kinda curious that Godot 3.x imports a Blender 3.1 GLB with consistent bone indexes every time, while they get all messy in Godot 4.0 with the same files...

[julienduroure]

@antourenein For Blender issue, please open a ticket here [1] with your test file. Thanks!

[1] : https://github.com/KhronosGroup/glTF-Blender-IO/issues

[TokageItLab]

One thought that comes to mind is the possibility that the sorting algorithm has changed in Godot4. I don't know if this is true or not, but if the bone indexes are ordered by hierarchical and use unstable sort (https://en.wikipedia.org/wiki/Stable_sort), it is possible that they could be randomized between some bones which have same hierarchy on import.

But I still recommend that you output gltf instead of glb and see how its contents change with the Blender output with opening it on text editor or something. So far, this issue lacks information to determine if it is a Blender bug or a Godot bug.

[antourenein]

Alright, I created a minimum representation of the model and its blender scene, which reproduce all the problems without needing to carry the entire original model.

I replaced it with a simple dummy, removed its huge list of animations, and left it with the idle animation only, for simplicity's sake.

Godot_v4.0-alpha9_win64_FkeGkEcl9f.mp4

Here's a folder with a minimally similar setup to the one I'm using in my project:

dummy-scene.zip

The structure looks like this:

The scene has a simple AnimationTree setup and a LookAtTarget node, which is the target the SkeletonModificationStack3DLookAt references (if it doesn't work, just move the node around the structure and it should cache)

The "original" folder contains the gltf exported from Blender 3.1 that works with the "dummy-setup.tscn" without problems. This is the same "dummy.gltf" that is in the root. The "alt" folder contains a gltf that was exported after closing and reopening Blender 3.1. If you replace the "dummy.gltf" and its binary in the root folder with the one in the "alt" folder, the "dummy-setup.tscn" looks just utterly broken.

I've included an export from Blender 3.2 in the "blender3.2" folder, too, for reference.

Now, here is the blend file, so you can try the export process yourselves and investigate what might be happening:

dummy-blend.zip

This blend file has my gltf export settings saved, too.

(Note: there's a strange bug in the GLTF exporter in Blender 3.1 that keeps re-activating the option "Optimize Animation Size" under "Animation". When exporting, please remember to deactivate it in Blender 3.1. In Blender 3.2 this does not happen, so you can just export normally, it will be deactivated as per GLTF export settings.

Also please remember to press A in blender to select everything before exporting, as my settings only export the selected objects. Or you could just deactivate that setting.)

[TokageItLab]

If you open alt/dummy.gltf and original/dummy.gltf in a text editor instead of opening them in Godot, you can see that the order of the nodes in them is different. So, it is not a bug in Godot for now.

Previously, we changed to use BoneName instead of BoneIdx in some Class to solve this problem, but it still looks unstable. And I am planning to discontinue it in #61596.

---

I can think of an alternative solution to this: after building the BoneTree in Impoter, reorder the items by BoneName and reassign the BoneIdx, which will generate a same BoneIdx regardless of the order of the nodes, unless the number of bones or bone names change.

However, as a side effect, the order of the tree on gltf is different from the order of the tree in Godot; Since the parent BoneIdx is also reassigned when reassigning, the parent-child relationship is not different, but the order of the siblings is different. For example, the little finger may be listed before the thumb in Enum. Except for that problem, we can stabilize the imported BoneIdx.

However, that is just a compromise and might be better implemented as an option.

After all, this is due to the problem of "unstable order of glTF Nodes output from Blender", so I think the right way is to solve that in Blender.

---

How do you think @fire?

[fire]

Fixed in KhronosGroup/glTF-Blender-IO#1659

[antourenein]

I tried out exporting the scene from a new daily build of Blender 3.2 RC and it seems all problems relating to bone indexes really have gone away, as well as the strange twisting of bones!

Thanks for looking into it!

[julienduroure]

This bug is fixed on Blender side since June, this ticket can be closed!

[fire]

Sounds good. Can close any time.