When using AnimationPlayer with Capture and Cubic Angle, it does NOT take the shortest rotation path

[wjl]

Godot version

4.0.3

System information

Linux (but happens on every target)

Issue description

• Scenario
  • You have AnimationPlayer with a Capture track using Cubic Angle easing controlling the rotation of a sprite.
• Expected Behavior
  • No matter what the current rotation is, the animation should take the shortest angle of rotation.
• Actual Behavior
  • The animation does NOT take the shortest rotational angle.
  • This often results in weird and unexpected spinning through the largest possible instead of shortest possible angle.

Strangely, if I change the Capture track's easing to Cubic, instead of Cubic Angle, it actually works as expected in the demo project I made, but that does not fix the problem in my real project, nor would I expect it to -- I actually need the documented behavior of Cubic Angle, which is to ensure the shortest rotational angle.

Steps to reproduce

1. Make a sprite.
2. Add an AnimationPlayer.
3. Make a track, "run", that's 2 seconds, Cubic Angle easing, with three sprite rotation keyframes: @0: 0, @0.5: +5, @1.5: -5
4. Make another track, "stop", that's 0.5 seconds, Capture mode, Cubic Angle easing, with one sprite rotation keyframe: @0.5: 0
5. Play the "run" animation, verify that it basically swings back and forth.
6. While "run" is going, switch to the "stop" animation during the first half of the animation: it rotates back to 0 normally.
7. While "run" is going, switch to the "stop" animation during the second half of the animation: it spins around taking the longest possible rotational angle path back to 0.

This also happens with Linear Angle easing, the "Cubic" part of it doesn't matter.

Minimal reproduction project

bug.zip

[wjl]

I said in my initial submission that switching to "Cubic" instead of "Cubic Angle" fixed the demo project but not in my real project (where things are significantly more complex). However, I just went and changed every instance of "Cubic Angle" to "Cubic" and every "Linear Angle" to "Linear" in all animations my real project and this does fix the problem. (It did not fix the problem to just change the Capture tracks -- so maybe something more complex is going on here.)

Is it possible that the behavior of "Cubic" and "Cubic Angle" is switched or something?

Either way, the demo project and reproduction steps I provided show the bug, I just wanted to give a bit more info of other things I tried on my real project just in case it helps debug this.

[wjl]

After more experimenting, it seems like the easing ("Cubic" or "Cubic Angle") on the capture track doesn't appear to matter, what matters is the easing on the interrupted track. If it's "Cubic Angle" this problem comes up, if it's "Cubic" this problem doesn't appear (that I have seen). I can reproduce this both in the demo project I posted and in my own more complex real project.

Either way, this doesn't work as it should, but again trying to help give more info to find the root cause. =)

[TokageItLab]

The cubic interpolation takes one previous key and two later keys from the current key for a cubic calculation as the name implies. I know there are some issues with the capture mode that the behavior is not consistent to begin with (#48432, #55110), but I think there is an additional issue with the failure to get the correct keys when it consider captured key as current key.

[akien-mga]

In case you still have a project trying to make use of CAPTURE in 4.x, could you assess whether #86715 solves the issue the way you would expect it to? You can test the PR by download a build (artifact) for your platform from the "Checks" (CI) tab.