AnimationTree blend - initial rotation ignored when using root motion and changing the blend value in code.

[ModularNucleus]

Godot version

v4.0.beta2.official [f8745f2]

System information

Windows 10, Nvidia RTX3060Ti, Studio driver 512.59, Vulkan Clustered

Issue description

The issue is a bit puzzling, so perhaps there is something I have missed. Here is what I have observed:

When using root motion and blending in the AnimationTree - e.g., with a blend or blendspace node - between different animations that have initial rotation differences, it seems that those initial rotations are ignored when changing the blend value in code. When changing the blend value in the editor and then running the scene, those same rotation differences are taken into consideration.

In this particluar example I have three simple animations: walk_forward, walk_left and walk_right. The left and right animations have a +/- 90 degrees initial rotation offset around the root bone y axis in relation to the walk_forward animation. All three animations also have smaller rotations around the root bone y axis. It is only the initial 90 degree rotation offset that is ignored - the smaller rotations are observed:

When changing the blend value in the editor, things work as expected:

animationtree_blend_rotation_editor.mp4

However, when changing the blend value in code, the initial rotation difference seems to be ignored:

animationtree_blend_rotation_code2.mp4

Steps to reproduce

• Open the MRP
• Change the value of the Blend2 node in the inspector and run the project
• Observe that the CharacterBody respects the orientation of the blended animations by facing the direction of movement
• Uncomment the code line that changes the blend value, change the value and then run the scene
• Observe that the CharacterBody does not respect the orientation of the blended animations (and e.g., moves "sideways")

Minimal reproduction project

Root Motion Test.zip

[TokageItLab]

This is not a bug and it is a design issue. The root motion takes out only the difference transform value from the previous frame.

Perhaps including rotation in bones such as hips or sub_root_bone, or adding abrupt rotation in the next of first frame would be a solution to some extent, but it is not a fundamental solution.

But, when using root motion, the first frame transform of the animation is initial transform in most cases, so the use case of mixing root motion and non-root motion as in this issue, seems to be a corner case.