Any 180 degrees rotation between keyframes is inconsistent between animation editor and the engine

[aaron_mccoy (PleaseDontBanAaron)]

After much hassle, I’ve realized that any keyframe animation that does a full 180 degree rotation between 2 keys is inconsistent between the animation editor and the engine.

When doing some animations with some rotations going from 0 → 180 degrees, the animation editor will increase it positively, while the engine appears to go the reverse and decrement until it reaches the result 0 → 360 → 180 degrees.

This can cause issues like so:
Animation Editor Rotating 0 → 180:

Engine Rotating 0 → 360 → 180:

The reason I’m confident about this issue is that it has been reproduce-able for 3 different devs on 3 different devices. As well as trying to restart, using a new project file, re-uploading the animation, re-creating the animation, etc… It always gives the same results.

If you’re interested, here is the broken version of the animation before I added in-between keyframes to patch the issue:
AnimationId: rbxassetid://73898113247982

Creator Hub - Store

[Parraing]

Hi there! Thanks for your report.

Animating rotations can be tricky, especially when interpolating from one angle to the opposite angle.

What happens if instead of creating 3 keys (0, 180, 360) you create 4 (0, 120, 240, 360) or even 5 (0, 90, 180, 270, 360)?

Edit: Never mind, you did say you fixed the issue by adding intermediate keyframes.

Out of curiosity are you using Euler angles or Quaternion rotations?

Cheers!

[aaron_mccoy (PleaseDontBanAaron)]

I’m using the euler xyz rotations in the animation editor, is it even possible to use quarternion rotations in the animation editor?

[Parraing]

For curve animations you can decide if you want to define the curves as three separate Euler angles, or as an interpolation factor between two orientations.

But this is irrelevant in your case. The issue with your animation, as you correctly guessed, is that interpolating between two opposite orientations is unpredictable. This is because there’s an infinite number of “shortest paths” rotating the object from orientation A to orientation B. Adding intermediate keys to guide the interpolation is the only way to resolve that uncertainty.

[aaron_mccoy (PleaseDontBanAaron)]

It’s true that the uncertainty of the rotation can be resolved more than 1 way, depending on the use case, but it seems like both the animation editor and the engine decide to solve it deterministically in different ways. It would be helpful if they were both deterministic in the same way.

[Parraing]

Today the ACE and the engine each have their own implementation of the interpolation. That has been the cause of multiple discrepancies between editing an animation and playing it at runtime, the most infamous of them being the cubic interpolation (in and out being swapped).

We are working on using the engine animation system in the ACE. They will both behave the same way and what you see during editing will really be what you get at playtime.