Game-breaking regression on newest release involving Motor6D animations causing unintended changes in ZVector values

Reproduction Steps
REPRODUCTION PLACE: BUGREP3.rbxl (66.6 KB)
Link to game to see it yourself: Gacha Online ✨ - Roblox
(A temporary solution has been found by disabling AnimationWeightedBlendFix under Workspace, we are no longer affected by this currently, but will be again in the near future)

On a Motor6D rig, create an animation that sets the Z rotation to around -.1125, and note that the ZVector of the CFrame changes when the animation is played.
image

This does not happen with the overwhelming majority of other Z rotation values, but most notably causes issues when Z rotations change between positive and negative values
This is causing huge visual glitching in our game which is heavily dependent on the visual appearance of each character.
Before bug:
normal
After bug: (Using an animation that interpolates between a positive and negative Z rotation)
image

The game has not been updated since Feb 26, and this issue was first reported March 3rd, around 1PM MST. So this is not an issue on our end

It would be ideal if this change to animations was reverted, as there are also critical bugs involving animation blending that did not appear before today.

Expected Behavior
ZVector does not change when only Z rotation is modified, as can be noted by using almost every other Z rotation value.

Actual Behavior
Animations with Motor6Ds with Z rotation values at around -0.1125 cause changes in the ZVector matrix of the CFrame, causing Z-Fighting in our game that relies on precise ZVector values.

Issue Area: Engine
Issue Type: Display
Impact: Critical
Frequency: Constantly
Date First Experienced: 2022-03-03 13:03:00 (-07:00)

16 Likes

Upon further investigation, this seems to be an issue with weighted blending. Setting AnimationWeightedBlendFix to disabled fixes the issues above.

6 Likes

I am also experiencing issues with animations coming off as “stiff” and glitchy. Believe it is related because it started happening today as well.

(This is especially visible with the left arm in this video.)

4 Likes

i made a reply redirecting to the exact same post that i sent without realizing it has already been posted my bad

This repro case is specific enough that I can get you a definitive answer for this after a little digging into it tomorrow. My suspicion, that I will need to confirm, is that the rotation matrix you’re creating is so near to identity that it’s not surviving the new runtime’s encoding to quaternions and back to CFrames. The quaternions are stored as integers with enough precision to represent the smallest rotational change that would normally be visually noticeable in an animation, but not necessarily enough bits that two rotations that started different CFrames can’t end up becoming the same CFrame, just from the quantizing nature of encoding to fewer bits. Using the animation system to achieve tiny offsets or rotations in order to prevent z-fighting is definitely not something the system was designed for.

Are these characters R15? And if so, what is the nature of their construction? Planar skinned mesh? Feel free to DM me if there is proprietary tech here you don’t want to discuss publicly. There may be some simple changes to the character that could make them more future-proof against both animation and rendering engine changes.

4 Likes

I also have been running into this problem, as a number of my animations have become stiff and glitchy.
https://www.youtube.com/watch?v=KAetgxNcbLo
(did what OP did and fixed my problems)

1 Like

I’ve been experiencing this too, a Motor6D connecting my weapon and arm now feels like it’s animations are missing a few keyframes or just stiff.

Could you elaborate on what this video is illustrating? I see what looks like two characters playing identical animations, just from different camera positions. Even stepping through it frame by frame I cannot spot a glitch.

If you have a place file with the source of this animation, that would be super helpful in figuring out what’s different between this. I see the apparent jump in position of the left arm you refer to, but this animation is so fast and the camera is spinning around the character, so it’s a bit difficult to see what the true discrepancy is. I would like to try playing this in slow motion, on two characters side by side, one using each animation engine.

We are also seeing this in our game. Sometime yesterday a lot of animations broke.

Should we be disabling AnimationWeightedBlendFix as suggested by OP or can we expect a fix soon?

Yeah the animations in my game are acting very strange as well… it is unplayable.

Before:
https://gyazo.com/4000ade6c51d8000e61a65fee3e0a197

After:
https://gyazo.com/2e15c5c106cb7fdc64692799e271fc42

I can provide animation sources & place file in DMs if you want them

1 Like

I’m having issues with my animations as well. After troubleshooting I’ve found out that the last key frame of all animations (either r6 or r15) doesn’t load in or play. For some of my animations I set the last key frame’s name to “Finish” but KeyframeReached doesn’t find it when the animation finishes. Before updating roblox the animations were working fine so I’m sure it’s a bug on roblox’s end.

This is a bug on our end. I’ve found the problem and am working on fixing it right now. You should disable Workspace.AnimationWeightedBlendFix until the fix for this ships.

8 Likes

Same here, my skydiving animations are broken in game. Studio still behaves the old(expected) way. I’ll have to look into this opt-out setting.

edit: disabled this setting and my animations are back to normal.

my walk anim in my game is bugging too. You guys cannot make AnimationWeightedBlendFix mandatory. It needs to be toggleable

Good news! I found the root cause of your Z vector issues, and I can fix this without you needing to re-upload or change anything to be compatible with having the AnimationWeightedBlendFix Enabled.

The compression of quaternions to integers was a red herring. The real problem turned out to be in our C++ quaternion library where floating-point quaternions very near to identity (but not exactly 1,0,0,0) were being converted to axis-angle format with an arbitrary axis. This was probably done to avoid the numerical instabilities of normalizing the near-zero-magnitude imaginary part, but the threshold wasn’t small enough to prevent visible artifacts.

I will follow up when the fix for this issue is live, so that you can opt back into the faster runtime engine.

7 Likes

Just circling back here, this fix has been live for a while!

1 Like