Animationtree blending issue

[Kliefer]

Godot version

v4.1.1.stable.official [bd6af8e]

System information

Godot v4.1.1.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4070 Ti (NVIDIA; 31.0.15.3640) - Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (8 Threads)

Issue description

In our 3D project we have a certain problem with the animation tree blending. We saw some issues similar to ours but not that it is the same in our opinion.
We are using .dae for the animation and .fbx for the skinned mesh because the import just deletes unused tracks in the animation which we will also write a more detailed version for this issue.
While blending animation via the animation tree we found a problem that if you have an aniomation that is 178° and you want to blend it to an animation that ist for example -178° the entire bone is flipping in the other direction all the way around. So instead of rotating 4° it rotates instead 360°
Other thing to note is that it seems that the animationplayer blends the animations diffrently than the animationtree because we didnt encounter any of the listed problems there atleast for smaller angle flips.

We also tested this in our animation software namly Autodesk Maya (2019 -2024) and other Game engines which are Unity and Unreal see the video attachments below

2023-08-23.18-53-35.mp4

The Bug in Godot the flickering of the weapon is the issue

2023-08-24.17-11-53.mp4

2023-08-23.18-39-34.mp4

2023-08-24.22-54-57.mp4

a more extrem example with a 360° animation which unity can handle it without a problem

unreal_test.mp4

The same animation in Unreal

Steps to reproduce

• Create two animations and both are close 180 in our one animation is ca. 179° and the one to blend to is ca.182°.
• Create an Animationtree and load both animation in inside the animationtree statemachine
• Connect animation A and B, then set a blend value of 0,1 (that a value is present)
• Play the animation with the blend and see how the angle and the animation is flipping

Minimal reproduction project

Testproject.zip
To replicate the issue go to the animationtree and blend between the animations

[TokageItLab]

Probably the BoneRest of the weapon is incorrect. Bone interpolating select a path that is closer from the BoneRest in AnimationTree's blending.

For example, when blending a high kick with a back kick, the leg must avoid to a fracture where the leg blends through the body, so the leg BoneRest should be on the ground. See also https://docs.godotengine.org/en/latest/tutorials/animation/animation_tree.html#for-better-blending.

[Kliefer]

The BoneRest of the Weapon Bone is on 0,0,0 under the Rootbone and other engines had no problems with the animationblend.
We had a problem with script with a similar behaviour and we fixed it with this function :

https://ask.godotengine.org/27625/equivalent-of-gamemakerss-function-angle_difference?show=27631#a27631

Maybe that could help you with quaternion interpolation so that there is no longer a long quaternion artifact

[TokageItLab]

Other engines are supposed to treat Humanoid as a special bone, but Godot treats Humanoid and other bones no differently, so BoneRest is important. Or it is possible that other engines do not interpolate high kicks and back kicks well.

If the weapon's BoneRest is pointing up by 0, 0, 0, it means it should be pointing down as BoneRest 0, 180, 0. Then if interpolation does not work as a child of Root, it should be a child of hand. And another option is using BoneAttachment.

[Kliefer]

We already usedBoneAttachments and parenting the weapon bone to the hand yielded the same results sadly.

But thank you for looking at this problem and taking the time with it.

[TokageItLab]

Your R_Weapon_Hand Rest:

But in walk:

So your R_Weapon_Hand Rest needs to face back like:

Fixed project:
Testproject.zip

If the weapon needs to be pointed backwards for equipment storage, it is recommended to nest the extra bone or add animations to the MeshInstance for flipping.

[jcarlosrc]

It seems devs do not want to address this issue. It's gotten unnecessarily complex to make basic animations to deal with the way Godot blends them. They cannot be just imported. The animators need to design them with the way Godot manages them in mind. Not good.

[TokageItLab]

As previously mentioned in #81755 (comment), the shortest path interpolation based on the current animation has the following serious unusable problems:

Unpredictable rotations: It does not make sense to get the shortest path from the prev frame. Even if it is the shortest path when comparing blended animations' current frame, it may will be the not shortest path by progression of the animation during blending. At the moment it is no longer the shortest path, the blending will cause an unintended flip.

Moreover, if we want to do it with Godot, the blending result depends on the iterating order, meaning that the same amount of blending will change depending on the order in which the nodes are connected.

Probably any DCC software, not just Godot, will have to choose between that using current frame interpolation with unusable problem or a deterministic solution based on rest.

Also, if using solution with rest basis, there is a workaround to rewrite rest depending on state as mentioned in #88805 (comment). It is the programmer's role, so there is no need to mind about this on the animator's side.

[MatthewBlanchard]

As previously mentioned in #81755 (comment), the shortest path interpolation based on the current animation has the following serious unusable problems:

Unpredictable rotations: It does not make sense to get the shortest path from the prev frame. Even if it is the shortest path when comparing blended animations' current frame, it may will be the not shortest path by progression of the animation during blending. At the moment it is no longer the shortest path, the blending will cause an unintended flip.

Moreover, if we want to do it with Godot, the blending result depends on the iterating order, meaning that the same amount of blending will change depending on the order in which the nodes are connected.

Probably any DCC software, not just Godot, will have to choose between that using current frame interpolation with unusable problem or a deterministic solution based on rest.

Also, if using solution with rest basis, there is a workaround to rewrite rest depending on state as mentioned in #88805 (comment). It is the programmer's role, so there is no need to mind about this on the animator's side.

Man I don't know how you can say this with a straight face. Every other engine in this example just worked when they imported the animation. Your continued closing of these issues and recommendations of jank fixes for BASIC animations is absurd. Can you please just mark ONE of these issues as an actual bug and leave it open?

I'd rather deal with whatever the consequences of the shortest path + advanced blending are then have my animation blends require a hand tailored JANK code fix.

[TokageItLab]

As I mentioned above, the only thing we can deal with here is how to set up REST. Changing the underlying blending algorithm should never happen.

Most of these problems have been reported when users import models from outside without being aware of rest and without using retarget. The cause of this (#81021) issue was also that retarget was not used.

The issue has never been submitted which compared to Unity or Unreal yet. Also, since those game engines implicitly do retargeting, comparisons with godot should be made with cases that use Godot's retargeting feature. Other game engines possibly use other blending algorithms only in the case of non-humanoid joints, but you need to evidence that they are not broken by the game engine in complex blends.

As I said above, simple on-the-fly slerp may be adopted in DCC software where the blend tree is not expected to be large, but the game engine may accumulate a number of rotations, which can easily break the user's intended blending.