[4.3] Mesh disappears when importing an AnimationLibrary onto a GeneralSkeleton

[Flynsarmy]

Tested versions

• Reproducible in 4.3-dev6
• Not reproducible in 4.2.2.stable

System information

Windows 11, geForce 4080, Godot 4.3-dev6, Forward+

Issue description

I have an anim library I've applied a bone map on and an armature with mesh I've also applied a bone map on. Both are taken from mixamo. When I create an inherited scene from the mesh GLB, add an animation player and import my anim library in 4.2, things work exactly as they should. The same process in 4.3-dev6 causes the entire mesh to disappear.

Example video: https://www.youtube.com/watch?v=9Ob5M0YIgQs

Steps to reproduce

• Have a character and some animations downloaded from mixamo. Mine are in an anim library.
• Apply a bone map with default settings to both the character and anim library.
• Create inherited scene from the character GLB. Add an animation player
• Load the AnimationLibrary into the anim player

Minimal reproduction project (MRP)

Godot 4.2.2 project: TestMixamo42.zip Godot 4.3-dev6 project: testmixamo43d6.zip

In both:

• Open Main.tscn
• Click on the AnimationPlayer and load the animation library

[matheusmdx]

Bisect points to #90064 as the culprit:

[TokageItLab]

I think this is an intended behaviot rather than a bug. Is the Hips scale track you intended? If you don't need it, enable the remove unimportant track option.

[TokageItLab]

Oh sorry I, the scale track is not removed with that option.

So, do we need an additional option to remove the scale track? Also, I am wondering what the scale track is on the software that created the glb. We need to determine if there is a problem with the scale track conversion (Apply Node Scale) or if the animation is oddly to begin with on DCC.

[Flynsarmy]

For the mesh I downloaded the fbx from mixamo, imported into the latest Blender, changed nothing and immediately exported as glb with default options - just the animation checkbox unchecked.

[fire]

I, @TokageItLab and @lyuma are looking into this.

[lyuma]

Thank you for providing the reproduction project for4.2.x. I can confirm that the issue is also present in that version (tested on 4.2.1) when Remove Immutable Tracks is unchecked.

The reason Remove Immutable Tracks concealed the problem in 4.2 is it removed all tracks that had only one keyframe if the initial pose was the same as the keyframe.

[TokageItLab]

The problem is that after applying Apply Node Scale, the Scale track values mismatch with the Skeleton's rest.

Even in 4.2.1, Remove Immutable Tracks did not specifically hide the problem, but guaranteed that the rest would match the Skeleton Node, so removal there made sense.

Since https://github.com/godotengine/godot/pull/90064, Remove Immutable Tracks is now done after Apply Node Scale, so the comparison needs to be changed.

@lyuma The current importer process matches which of the following flows? Or other?

1. Override Rest -> Fix Silhouette -> Apply Node Scale -> Remove Immutable Tracks
2. Override Rest -> Fix Silhouette -> Remove Immutable Tracks -> Apply Node Scale
3. Apply Node Scale -> Override Rest -> Fix Silhouette -> Remove Immutable Tracks

If Remove Immutable Tracks is running after Apply Node Scale, there are two possible fixes.

• Move Remove Immutable Tracks before Apply Node Scale
• Apply Node Scale to all keys in the scale track

Probably the former should be chosen, since the latter could corrupt the animation if the bones have scale intendedly as glTF. But considering the role of retargeting in matching the appearance, the latter may be preferable, then we need to be careful if the glTF specification allows such cases as Scale of 0.

[lyuma]

Probably #3. It is incorrect to remove tracks before the retargeting flow. We need to be able to compare against the bone rest. The reason is because animation mixer may use bone rest as the reference point when no explicit reset animation exists (and indeed, when the user requests creating a RESET animation, it is based on the bone rest)

Move Remove Immutable Tracks before Apply Node Scale

This is incorrect, because it will remove things that match the old bone rest which will then lead to incorrect blending after we change the rest.

I strongly believe that this bug is unrelated to Remove Immutable Tracks. It only appeared to be related because remove immutable was incorrect previously

Apply Node Scale to all keys in the scale track

This is kind of what I am trying, but the code is written to only touch the toplevel bones (get_parentless_bones)