3D bone attachment position incorrect when importing from Blender

[ZachAR3]

Godot version

4.0.beta.7.mono

System information

Endeavour OS Zen Kernel 6.1 Ryzen 5900x Nvidia GTX 1060 6GB (proprietary drivers)

Issue description

When importing my character rig from Blender into Godot 4 as a GLTF the weapons which are parented to bones from the rig are placed improperly breaking the animations. This issue doesn't occur in the latest Godot 3.5 so it's likely a regression issue.

Steps to reproduce

Make an armature in Blender, add custom bones and parent meshes to said bones. When importing into Godot 4 the positions will be incorrect.

Minimal reproduction project

GithubBrokenAnimationsProject.zip

[SaracenOne]

Confirmed, it seems to be caused by tracks being created for the objects assigned as children of the bone attachments being put in the wrong place. Will investigate further.

[SaracenOne]

Okay, so this is actually quite a tricky bug. It would appear that the way we're handling the offset of nodes which get created with bone attachments is COMPLETELY messed up, and in fact, it's messed up in 3.x too. The only reason it works in 3.x is because for whatever reason, we don't create tracks for meshes which don't directly have explicit keyframes, whereas we create them in _optimize_track_usage function. We can probably hack our way around this to restore 3.x-like behaviour, but we probably want to completely overhaul and re-evaluate how this aspect of the import pipeline works.

[SaracenOne]

I can tell you why it's doing that now and while this doesn't fix the larger issue, it will at least be a temporary workaround. Go into the advanced import settings for your glb file, click on the AnimationPlayer node and set the import track settings to this. This does not fix the broader issue, but will at least make it behave like it did in 3.x. I consider 3.x's behaviour to be broken too, this is specific issue is a symptom of a much larger problem.

[SaracenOne]

It's also worth noting that this model's import seems to be broken in Blender's GLTF importer too. I'm not sure what the correct behaviour is actually meant to be in relation to the spec or maybe this model was exported from a broken GLTF exporter. Will likely require deeper investigation.

[lyuma]

@ZachAR3 I have determined the issue is because you are exporting from an old version of Blender with known bugs.

Please update to Blender 3.4 or later and see if that solves your issue. I'm going to close this issue, but please reopen if you continue to have trouble after exporting from 3.4 or later.

Here you can see glb exports from Blender 3.2 and from Blender 3.4: PlayerFPS_exports.zip Blender 3.2 shows the issue:

but Blender 3.4 does not show any issue:

Thanks for reporting the issue though. This file certainly made for a good testcase. Please continue giving the whole import pipeline a good test before 4.0 is shipped so we can catch more issues like this.

[lyuma]

The only mystery is why "This issue doesn't occur in the latest Godot 3.5"

That slightly baffles me, given that the problem even showed up in Windows 3D Object viewer as well as reimport into Blender itself. I tend to take https://gltf-viewer.donmccurdy.com/ as a source of truth and it also shows the problem with the 3.2 export but not the 3.4 export.

My only guess is perhaps Godot 3.x has another bug which somehow counteracts the bug in Blender's export, (sometimes two bug can cancel each other out) but in any case it was not conforming to the glTF spec, so it's not behavior we would be able to keep in Godot 4 and later.

[ZachAR3]

The only mystery is why "This issue doesn't occur in the latest Godot 3.5"

That slightly baffles me, given that the problem even showed up in Windows 3D Object viewer as well as reimport into Blender itself. I tend to take https://gltf-viewer.donmccurdy.com/ as a source of truth and it also shows the problem with the 3.2 export but not the 3.4 export.

My only guess is perhaps Godot 3.x has another bug which somehow counteracts the bug in Blender's export, (sometimes two bug can cancel each other out) but in any case it was not conforming to the glTF spec, so it's not behavior we would be able to keep in Godot 4 and later.

Not sure, Thanks for all the help! The problem ended up being fixed by going back into blender and rekeyframing the first frame of each action, and somethings even broke in blender and I had to redo them so it was definitely partially due to a broken project.