Update: this change is now live as of 04/06/2022 3PM PDT
Hello developers,
In February we announced updates to the animation throttler and received great feedback from all of you. Today we’re excited to announce that the animation throttler is graduating from an opt-in feature to opt-out!
All places with the Workspace.ClientAnimatorThrottling property set to Default will have animation throttling enabled this week.
With the improvements we made based on your feedback, we’re confident that the animation throttler should work well for most places in Roblox. However, we would still love your feedback on bugs and what we can improve.
Bug fixes and improvements
We made several improvements and bug fixes since our last update in order to ensure a smooth rollout for animation throttling:
Reduced max throttling intensity to reduce the visible impact of throttling on animation quality
Improved visibility checks to ensure that a model’s animation throttles more intensely only if all of its parts are offscreen
Changed visibility calculation to include camera FOV so that animations don’t throttle as intensely when zooming in
Fixed a bug where models would throttle too intensely if they had animations that applied locomotion to the root/body bone
Among these fixes, we made many other small changes that improve the consistency of the throttling algorithm.
How to disable throttling
If for any reason animation throttling does not work for your place, you can disable it using the Workspace.ClientAnimatorThrottling property:
As always, thanks for helping us improve animation throttling with your feedback. We’re always happy to hear more from our developers, and we’re committed to making this feature work well for everyone!
The throttler should only have impact on the animation update frequency on characters that are not highly visible, and shouldn’t affect normal humanoid locomotion. In the vast majority of sprinting implementations in Roblox places there shouldn’t be any issue.
Thanks for your feedback. We would love to know how we can improve the throttler so that you can also benefit from the improved performance in your places!
Currently the throttling has an effect where it “blends” animations together.
Say I want to play an animation with Action priority, but there’s also another (looping) animation that was previously playing on the same priority. The looping animation has the character’s right arm at a 0* angle (perpendicular with the ground/baseplate). The other animation has the character’s right arm at a 90* angle (parallel with ground).
When both animations are playing simultaneously, I’ve observed that the animation throttling behavior causes the character’s right arm to take an angle around 45* instead of 90*. I’m unsure if this is the animation throttling feature or not, though it is the most likely cause.
This is really the only reason I’m opting out of the program, as some scripts end up playing animations closely together enough to each other such that they look and feel different than a developer (or developers if you’re using Team Create) may have intended.
EDIT: This is most likely AnimationWeightedBlendFix instead, I did a few additional tests.
Whenever updates use the term “moving to opt-out”, this to me has always carried the implication of “the old behaviour is going to be removed”. Could it be clarified if animation throttling is intended to be forced or will the engine remain compatibility for experiences that don’t want to use throttling? If it’s intended to become permanent behaviour, could the vision behind this decision be explained?
@CatzRule_81 Glad you were able to track down the root cause. As you’ve seen in your testing, the Workpsace.ClientAnimatorThrottling property should only affect the rate of animation updates, and does not change how animation are blended, that’s the purview of the Workspace.AnimationWeightedBlendFix property. Seems like you can give throttling try still .
@colbert2677 Thank you for the question. That’s a good place for us to add a bit more clarity regarding this feature. As of right now, our plan is to keep throttling as an opt-out feature for a while - at least a few months if not longer - until we feel truly confident that the feature is iron clad and ready to become a seamless engine feature.
We expect this process to last a long time and to include comprehensive feedback from our developers before the option opt-out is removed.
Every three-phase rollout does have the intent of eventually removing the old behavior, but in a way the mechanics are exactly the opposite of what you suggest: Moving to opt-out helps us identify exactly which remaining developers the old behavior can’t be removed yet because of.
In the opt-in phase, there may still be some developers out there who are significantly impacted by the change but who weren’t aware of it or thought they wouldn’t be impacted and didn’t try it out. Once the feature moves to a feature moves to opt-out we know for sure that everyone is aware of the change and anyone who cares about the old behavior has the feature set to Disabled and we can do things such as individually reach out to them and find out what their issues are.
Glad that this feature is moving along! In the gif provided, there is hardly a noticeable difference between having throttling on vs off! A performance boost like this is always great when the noticeable impact is negligible. I also really appreciate the smooth rollout of this and hope that everyone else can find a smooth transition into using it.
.