Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Flynsarmy opened this issue May 13, 2024 · 8 comments · Fixed by #92012
Closed

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

Flynsarmy opened this issue May 13, 2024 · 8 comments · Fixed by #92012

Comments

@Flynsarmy
Copy link
Contributor

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.

image

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
Copy link
Contributor

Bisect points to #90064 as the culprit:

image

@TokageItLab
Copy link
Member

TokageItLab commented May 14, 2024

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
Copy link
Member

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

image

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
Copy link
Contributor Author

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
Copy link
Member

fire commented May 15, 2024

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

@lyuma
Copy link
Contributor

lyuma commented May 16, 2024

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.
godot_scaled_skeleton_4 2

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
Copy link
Member

TokageItLab commented May 16, 2024

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 #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
Copy link
Contributor

lyuma commented May 16, 2024

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Very Bad
Development

Successfully merging a pull request may close this issue.

6 participants