New ClientAnimatorThrottling Property

Hello Developers,

As some may have already noticed, we released a new property Workspace.ClientAnimatorThrottling.

This feature enables under-the-hood performance improvements via LoD and requires no other changes other than enabling it. With this you can see a higher FPS for minimal visual quality change.

Rollout Plan

Starting Today

Workspace property ClientAnimatorThrottling is opt-in by default and only affects animators on the client.

Some animation artifacts can be expected (far off characters can appear to stutter through movements for example). We would recommend considering the importance of animation fidelity versus the tradeoff for performance in your specific experience when using this feature.

Feature disabled:

Feature enabled:

What’s Next

We are planning further generalization and tuning improvements of the LoD system based on feedback (subject to change). In the future we will also switch the feature from opt-in to opt-out, more on this later.

That covers it for now. We’d love to hear more about use cases for this new feature or any ideas for future direction!


This topic was automatically opened after 10 minutes.

Such a simple addition that barely changes anything visually but will probably help a lot developers when they’re working with a lot of animations in a single place, amazing update!

Just a question though, can we change this on the client so we can let the user define their animation LOD? Or is it a setting we can only set via studio?


Does this mean that animations on the client will no longer “lag” when it comes to NPCs


This looks great! Although from a developer perspective I feel it would suit best to add a slider or value to tune what distance animations start getting choppier. It would help developers to have more control over their games and how the animations are displayed.


While the example is a bit extreme to show off the tech, there does seem to be a significant difference & I wonder if there will be options for different degrees to this affect? Like a None, Medium, Max potentional, so we sacrifice some smoothness to gain performance, but not too much, while others have the option to sacrifice more.

And as said right above me, overall more control is much appreciated.


Great feedback! We will take into consideration more controls in the next phase of updates!


The crown dance On this crowd From the cilentanimatorThrotttling?.


That’s a good idea! Currently it’s only set via studio, but we are taking the feedback to work on future updates.


Hey! This is a great feature, but this may be potentially game-breaking for our studio depending on how this is implemented.
Our experience has the client calculate hitboxes on the client through raycasts, which means that our hitboxes are dependent on animation behavior.
While I’m assuming the client will not have animation LoD enabled for it’s own humanoid (or, at least be higher prioritized - clarification would be great), I’m unsure on how this would work on the server.
The animations are played on the client, which means they should replicate to the server, but in order to verify on whether the hit data was exploited or not, the server holds a cache of each player’s limb CFrames during the last second, and backtracks accordingly.
With this throttling feature, would there be any inaccuracies on the server when it indexes the Part.CFrame property? If yes, is there any way to have Part.CFrame be as accurate as possible to the original source of truth?


This should not effect animations on the server to my understanding. The behaviour throttles animations based on the player’s distance to those animations, but, ofc, the server doesn’t have a camera or character, or any concept of streaming distance, because its the server.

So I can’t imagine it will effect the server in any way.

(You may actually be more worried about the client hitting a throttled animation and the animation on the server already having moved, but, I think this isn’t going to effect gameplay much, it would be effectively equivalent to having a low FPS for very far away targets)


The client’s own humanoid and nearby characters will be the highest priority and should not receive any LoD under normal circumstances.

In practice, the cframe data that clients replicate to the server should be these non-LoD’d humanoids which have the highest animation priority.

Hope that answers some concerns, and definitely bring up any issues that are encountered!

Additional note:
I believe for melee interactions this should not be much of an issue.


This is actually an amazing feature. This is definitely going to help with experiences using a lot of AI, or servers with a lot of players. Unexpected, but great feature!


I’m not sure how widespread this is, but ever since this update released we’ve been having issues with new servers being created at our game, we haven’t enabled this property.

When joining and creating new servers on our game here: Pinewood Computer Core everyone has been getting disconnected with the error "There was a problem receiving data, please reconnect. (error Code: 260) or "this experience is currently unavailable, Please try again later (error Code: 517) with only one server working so far, the game hasn’t been updated today so it is strange to now be having issues with joining brand new servers.


Seriously been loving these incremental performance updates recently :white_heart:

This will make a huge difference in games with lots of NPC’s


This can be useful for some hams with lots of NPCs but besides that in smaller games it just makes distant players look laggy


I really like this optimization option. Our experience relies on a large number of humanoids so this is a nice toggle to use.

One issue I found is that it doesn’t update immediately for humanoids that instantly teleport using CFrame. We have an enemy humanoid that teleports around the arena and sometimes instantly to the player, and while far away it looks quite alright, but when it teleports up close, the humanoid is still stuck in the “throttling” mode even if they are right on top of your character. Would this be considered a bug?


This is really good.
However one thing bothers me that the distance for animations to throttle is really low, making gameplay look really disorienting.

It should at least be doubled or even quadrupled.

We probably should have more control over this as currently the throttling distance is wayyy too short.


Also one thing?

Does this affect custom setting of the .Transform properties of humanoids via the .Stepped event?


Does this take into account the size of the characters animating? My game is about custom characters and I will need the LoD to be smarter than simply being tuned for default avatars or it will look very very bad on large birds in my game.

Anything to do with avatars should come with a suite of settings; custom characters keep getting shafted because of the lack of customization afforded to features that affect nonstandard avatars.