BoneAttachment3D serializes bone_idx after bone_name: the index is off when skeleton changes and model is reimported

[jitspoe]

Godot version

v4.0.alpha.custom_build [2475393]

System information

Windows 10, GLES3, NVidia RTX 3080

Issue description

If you have a BoneAttachment3D attached to a bone, on an imported .blend file, then you change the blend file to add or remove a bone such that the index of the bone it's attached to changes, the attachment will be on the incorrect bone but will display the correct bone name.

Not sure if this happens with BoneAttachment in Godot 3.

The tscn file stores both a bone_idx and bone_name, so it should be possible to, on reimport, find the correct bone by name if the bone idx doesn't match the one with the name.

Steps to reproduce

• Create attachment on a blender file you've imported with multiple bones.
• Remove or add bones to the armature forcing the indexes to change.
• Note that your attachment is attached to a different bone than it states.

Minimal reproduction project

Here's a .blend file that reproduces the issue. Add main_character.blend to your scene, attach to "head" or "hand_r", then copy main_character_after.blend to main_character.blend and note the attachments become broken.

... well, "something went really wrong" when I tried to attach it.

Edit: After editing a comment, apparently I can edit this with the correct text (hopefully). Here's the .blend files to reproduce this.

character_bone_index_problem.zip

[jitspoe]

Actually, this problem is worse than initially described. Every time I re-save the .blend file, it seems to shuffle the bone indexes, even without modifying the skeleton.

Edit: I was able to work around this with a simple script.

extends BoneAttachment3D


func _ready():
	bone_idx = get_parent().find_bone(bone_name)

Seems more than just the bone indexes are getting messed up, though. I feel like the timing of my animation is off and sometimes the poses are getting jacked up, too, but I'll have to dig into that a bit to figure out what exactly is going wrong.

[jitspoe]

Seems I can upload files in a reply, but not in the main bug???? Here are the blender files.
character_bone_index_problem.zip

I can't even edit the original bug to put this link in, because when I try to do that, github shows the content for another bug that I entered as the edit text instead of this one. Things seem very broken here! Bugs in the bug reporting tool!

Edit: And here's a separate bug for the animation playback speed issue: #64594

[jitspoe]

The random bone index issue appears to be an exporter problem: #61641. I was going to close this issue, but I think it can still be a problem if the bone indexes are changed legitimately by adding/removing bones. On re-import, the bone attachments should probably update the index using the bone name.

[lyuma]

Hey! We believe we pushed a fix in #72162 (part of 4.0 beta16)
I'd be interested to know if it solves the issue here, since bone attachments are now named after the bone they are attached to.

If it's fixed, feel free to close the issue, but I'd love to hear your feedback either way.

Your scene might break after the update once, since we were forced to make a breaking change in beta16 in order to ensure it remains consistent in the future.
Thanks for the report!

[lyuma]

Ok, I misunderstood the bug report. This problem is still present, actually.

The attached .blend files do not work due to referencing other Linked blend files that were not included, so it was difficult to test.

But I realize the cause now. Check out how BoneAttachment3D is serialized:

[node name="BoneAttachment3D" type="BoneAttachment3D" parent="TestNew/Root/GeneralSkeleton" index="4"]
transform = Transform3D(1, 0, 0, 0, 0, -1, 0, 1, 0, 0.0173216, 1.44891, -0.00327493)
bone_name = "LeftEye"
bone_idx = 22

See the problem?

Both bone_name and bone_idx are being serialized, with bone_idx coming second. This overwrites the bone_name as the object is being read from disk, no matter if the bone name was found or not.

[jitspoe]

Does it actually try to get the bone index from the bone name first? If so, what's the point in serializing the bone index?