Animation Throttling is Moving to Opt-out

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.

Side by side comparison of animation throttling on v.s. off

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!


This topic was automatically opened after 10 minutes.

Great Roblox could implement this. Couple things…

…a heartbeat?!

Also, will this impact sprinting?
Great to see Roblox listening to our feedback.



I think I’ll be opting out of this, thank you.

This is commonly used for benchmarking, it’s nothing to worry about.


Very useful! Thank you roblox for hearing our feedback

1 Like

Hi Land,

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?

1 Like

@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 :slight_smile:.


@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.


How will this affect Constraints attached to Bones? Will the constraints be consistent with the visual?

1 Like

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.


I completely forgot about this! What was this again?

A small bug: the link leads to an error page.

1 Like

I still don’t understand. Does this function only work for animation on the client? Sorry for the stupid question, but I won’t be able to sleep.

I’ll always appreciate much needed performance improvements to the Roblox engine. Great job to the engineering team for this one.


Smooth animations work better on optimized games and look a lot better than before but I hope it doesn’t drop frames and ping in laggy games.

I think it means the fps, like RunService.Hearbeat:Wait() or RunService.Hearbeat:Connect(function() end)

1 Like