CFrame lerp orientation resetting sometimes

I’m using a custom animation player and the orientation of specifically the torso is wrong… sometimes, but not randomly, and only on two animations.

image
It is definitely this line of code that at least reveals the issue.
Both the first CFrame and the second CFrame are correct.
I can lerp between them with an alpha of 0 or 1 and they turn out normally.

However, even a static fractional value of alpha (like .001 or .85) will leave the torso with 0 orientation… sometimes.

Example:


This bug is not random, two of these animations playing at the same time will have the exact same problem.

This is the moon animation file of the animation:

It’s happening on an other animation, too: Same bug, only rotation is zero…
Here’s the moon animator view (bug time circled in red):

This is an animation that DOESN’T have the bug:

Possibly related, when I set my frame rate to 240, the rigs tweak out:

Why does a fractional lerp leave the orientation at zero, but only for the torso, and not on every frame, and not randomly?

1 Like

Motor6D Transforms don’t like non-orthonormal CFrames at all.

1 Like

True enough, but I don’t see how that solves the problem at hand. CFrame:Lerp does a Slerp of the CFrame rotation, and a Lerp of the CFrame translation, so if your animation data contains keyframes of all valid CFrames, you will not get non-orthogonal CFrames from a Lerp().

The fact that your character sometimes glitches upright, and other times disappears suggests that joints are sometimes ending up with NaN CFrames (which will make the whole character blink out of existence on that frame), and other times a transform is not being set on the Motor at all, which could result in it having zero rotation or translation on that frame, if the Motor6D transform is just identity.

All of this points to a bug in the animation player’s evaluator. Either it has a bug in how it choses the two CFrames to interpolate, or your animation source data is breaking some assumption made by the evaluator, like how close keyframes can be to each other, or the evaluator has some fundamental bug in its math somewhere. If you have 2 valid CFrames, and you use CFrame:Lerp to interpolate between them values of the interpolation parameter between 0 and 1 inclusive will not cause the problem you see. t of 0.001 or 0.85, etc.. are not a problem when the 2 CFrame arguments are both well formed.

AI responses on solved posts now?

I don’t use any AI tools, so I don’t know why you’d think that. I was trying to give you some possible explanations for what’s actually going on there with your gitching animations.

Also, FWIW, you’re supposed to mark a post as a solution if someone actually finds a solution to your problem and explains it in a way that might help other developers who have the same problem. Using it to just +rep yourself is pretty cringe, especially if you’re not even going to share how you solved the problem in a way that could benefit anyone else.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.