It is disappointing how this feature is being forced on all games (from what I can tell), as this broke my game’s animations (it works, but they look really weird), and I’m not easily able to get a fix out until after the deadline.
While the issue is minor for me now, this will likely break animations in many older games, especially RPGs, and many of these developers aren’t working on them anymore or don’t have the time to fix them.
Please make sure that any new change will never be forced on older FE-compliant games! It’s disappointing to have to constantly pop back into old projects just to fix another feature which Roblox unintentionally broke.
Nope.
No, no, no. No thank you.
This update is awful for games with really snappy animations, such as mine.
Here’s an example. This is how it’s supposed to look:
Each move has a distinct animation, playing in priority of the most recent action. It makes sense, especially because doing one action cancels the previous one. When it’s all put together, you can tell what’s going on – roll jump, glide, dive.
Here’s the “”“fixed”"" version:
It almost looks like all the animations are fighting for priority. Why? What’s causing the dive animation to tilt back like that? It’s like AI interpolating a 24fps animation to 63fps, it looks so ugly and there’s no way to tell distinct actions apart. In short, THERE’S NO SENSE OF PRIORITY BECAUSE EVERYTHING IS FIGHTING TO BLEND TOGETHER.
It looks gross. It might seem minor but it mars the complete aesthetic of the game. I put so much time and care into making sure it looks snappy and sharp, and now it looks smoothed out without any attention given to priority.
The great thing? All the animations stop. The animations don’t overlap, at least not for very long. And the priority enums are used. So what gives? There’s no rhyme or reason for any of this, and this leaves SO much room for unpredictability.
I genuinely don’t understand why this update is being forced. I understand the idea behind it – there was a bug that’s been here since the beginning and now it’s being ironed out. But that’s the thing: everyone developed their games thinking this is just how it was supposed to be. So why not create modifications that emulate the feeling of the old system? Otherwise, a bunch of other games are being left in the dust.
The really big question is this: Who is the majority that gains from this, and why can we not have our cake and eat it too?
We’re aware of the issue where setting Motor6D properties from script does not behave as it used to. This is not directly related to the blending or evaluation order changes, it appears to be an unintentional behavior change that just coincidentally happens to be in the new runtime evaluator code branch only. A few recent avatar and animation features, including retargeting and IK, were developed in the optimized runtime branch, so the AnimationWeightedBlendFix is now enabling more than just the original blending math corrections.
I don’t understand why they’re “”“fixing”"" this “”“issue”"" yet they’re refusing to fix the inverted easing styles bug? If Roblox is gonna make our development a hellscape to deal with, could they at least be consistent so we can expect what gets/is getting fixed and what isn’t?
I understand how, from the developer side of the API, it seems like we’re merely fixing a bug that some games rely on. In truth, calling it a bug fix at this point is misleading in regard to the scope of the change. The “fix” became a choice to not re-implement the incorrect blending math when we rewrote the animation track evaluator from the ground up to scale for the future needs of the avatar system. We had to make the blending work as intended, and as it has always been described in the online documentation. Correct linear blending of tracks is essential for things like multi-way locomotion controllers, FACS facial animation, and runtime retargeting. Freedom from play-call-order dependencies was also important, as I noted previously (above), especially for improving replication performance.
A bit more detail about just how much has fundamentally changed
The old runtime’s evaluator did the blending math with a combination of CFrames and Euler vectors. The new runtime does all its math–interpolation and blending–with quaternions, converting to CFrames only at the very end when applying to Motor6D.Transform. The old runtime evaluated tracks in low to high priority order, the new runtime reverses this to avoid evaluating anything that does not contribute to the final animation. The old runtime stored transforms in memory as CFrames, the new one uses least-3 quaternions encoded in a packed integer format, in order to support much larger animations. These are just a few of many very significant low-level differences.
The reason the old animation runtime cannot stay around is simple: it’s impractical for Roblox engineers to maintain redundant evaluators and to have to always consider both when features are added or changed. Branching core parts of a game engine to preserve backwards compatibility for a handful of games is a slippery slope that quickly leads to a bloated codebase that is a nightmare to work on and super confusing for new engineers to come up to speed on.
What I dont understand is the decision to NOT add int priorities. Now that animations dont play on top of each other it would be more useful than ever.
I can see some bit of potential with this (eg. flinching animations not completely interrupting idle animations) However, why is it that we’re not allowed to change animation priority by script/runtime? If we don’t feel like reuploading, we should at least be given the option to change them by code… Unless there’s already a way to? it’s pretty necessary to include something like this so we can at least swallow this mandatory update a bit better, especially when i have 10+ pages of animations to convert
It’s all well and good saying you can’t maintain backwards compatibility, because you can’t forever and that’s reasonable, but developers can’t always go back and “fix” their old projects. I am aware this won’t happen but thought it is worth a mention, with other game engines you can usually play any old games, as they essentially “come with” the older version of the engine.
There’s no reason Roblox couldn’t popup with a popup saying “this game was developed using an older version of Roblox, in order to play it you must download it.”
(Okay there are lots of reasons why not, but we can dream okay)
I feel like someone at roblox or in contact with roblox devs really just didn’t feel like learning how to make animations not affect other body parts, so now we have this disaster on our hands.
Now all of my animations feel sluggish and don’t move to the keyframe positions where they are supposed to be, thanks a lot
it’s impractical for Roblox engineers to maintain redundant evaluators and to have to always consider both when features are added or changed.
It’s impractical for developers to deal with all the crap you put us through. And besides, a “handful of games” is a MAJOR understatement, since it literally means nearly all games created with animations before this update.
The C0 and C1 property of Motor6D is affected by animations, which is unintended behavior.
I believe that this is a bug that came with this new feature, and it has been causing issues. Any animation playing over the priority of Core will affect these properties of Motor6D:
C0
C1
Transform
From my testing, this appears to happen with humanoids, but let me know if it happens on animation controllers too.
This issue needs to be fixed before the removal of Workspace.AnimationWeightedBlendFix as this is game breaking for many experiences that rely on scripted motor6ds and animations.
Found a bug report for it, best to support it for visibility:
Integer priorities would have had a much bigger impact on the animation editor. Adding a few values to an existing enumeration, intended to be used only to fix one particular bad usage pattern, was the quicker and simpler solution. There are currently more priority values available than any game should need. If you find yourself wanting to have more, it’s generally a sign that priority is not being used correctly. The intended use of a higher-priority is to temporarily override a lower-priority track, either fully or partially, when you want the underlying track to continue playing, either because it still contributes, or because you want the playback time to continue advancing while it’s being overridden.
Priorities are not intended to be used to simply have the latest track replace previous animations that do not need to continue evaluating. That is a bad pattern, one that was causing serious performance degradation in a number of top games, and one that adding arbitrary integer priority values would have enabled and encouraged.
Blendfix looks cool but its a feature that still need work, most of the animations especially if they are snappy usually don’t work. If you really want to add animation blending please add something similiar to unreal engine where you can edit animation blending variable for animation track instance between 0 and 1. I’m bad at explaining but what I mean is:
Blending with 0 will have 0 effect on AnimationTrack
Blending with 1 will play on top the Animation Track
Blending with 0.5 will make animation look like its in middle of transitioning etc.