During the past year we have made improvements to the Animation Throttler that we introduced first as an opt-in feature in February 2022, and then as an opt-out feature the following April.
In the next phase of the rollout, we’ll remove the Workspace.ClientAnimatorThrottling property, which means throttling will be enabled automatically for all places. We are committed to resolving any issues before this last phase of the rollout. Therefore, we want to hear from you about how animation throttling affects your places, especially if you either enabled or disabled the workspace property directly.
TL;DR for the Animation Throttler:
It improves performance particularly in places with lots of animated characters by throttling off-screen and far away characters more intensely.
Currently runs only on local clients.
Animation throttling is applied only to characters that are remotely simulated.
For example, your own avatar should never throttle in this system since it’s locally simulated.
On every animation update, the throttler collects high level performance stats, as well as per-character visibility information to determine a throttling intensity for each character.
Known Issue
[Resolved] Skinned Animations + RigidContraint issue - this issue was mistaken for an animation throttling issue, as it was causing Animations for skinned modes that used RigidContraints to throttle. We isolated the issue to a bug in the physics system resolved it in May.
If you have encountered issues with the Animation Throttler in your places or want to share any other feedback about the feature, please let us know below!
Thank you.
Update 10/05/2022
We have an exciting new update for you all! Based on your feedback, we added a new property Animator.PreferLodEnabled that’s set to true by default. When set to false, it hints the LOD controller to disable throttling on the particular character that holds the Animator instance. This should help address throttling issues with copying cframes from a character in the Workspace that’s off-screen to a character in a ViewportFrame.
It’s important to note that this new property is only a hint to the LOD controller, and is not a guarantee that the character will not throttle. There will be circumstances where the LOD controller may decide to throttle the character anyways (low system resources, too many animating characters, etc).
Thank you all for you feedback. We hope this helps!
This update brings improvements to any model, most commonly humanoid characters, that have an animation controller with animations playing on it.
Parts moving around the world don’t have animations playing and are instead controlled by the physics engine. This update does not bring any performance improvements to the physics solver specifically.
My games use standard animations but also manipulate the Transform of some joints after animations are applied (on Stepped). This relies on animations basically resetting the Transform each frame, which no longer occurs when throttling is enabled. Due to this these extra transformations keep stacking every frame.
What’s the proper (robust) way to migrate this to be compatible with throttling? I wouldn’t mind throttling these extra transforms as well. I was looking for a way to only apply these extra transformations whenever animations actually update on a rig, but I couldn’t find any robust way to do this.
I modify Motor6D CFrames of weapon animations dynamically to communicate the player’s current look rotation. using Vertical and Horizontal rotation for the head and Vertical rotation for the arms.
Trying to create animations to account for player lookat rotation would be extremely inefficient for development and when taking into account numerous weapons.
The documentation recommends using Transform instead of C0/C1 for animations, so using those instead feels like a nonideal workaround. According to https://devforum.roblox.com/t/new-property-motor6dtransform/46813 it seems like Transform is intended for purposes like this and performs better than using C0/C1 too.
Hi @Den_S! That’s a great suggestion. We’re exploring how to allow devs to perform these transform updates in Lua with throttling. We’ll make sure to post an update when we have something to share!
Is it possible you could add an Enable property to the Animate object?
I got alot of animations running in worlds that aren’t visible to the player (because the client puts all world folders except the active one in replicatedstorage) and I dont want those animation objects to use up any of my precious CPU.
I currently have an issue with animations looking choppy in a ViewportFrame when ClientAnimatorThrottling is enabled. I’m sure there are some other developers with games that render characters in a ViewportFrame. If the camera is not directly facing the character in said Frame, Animations will play choppy like this.
ClientAnimatorThrottling Enabled
ClientAnimatorThrottling Disabled
Is there any way to prevent select humanoids animations from being throttled? Having this always turned on by default would be very bad for my game.
One possible workaround is manually interpolating the C0 and C1 of each Motor6D of the characters you don’t want the throttling to affect. You would have to save the C0 and C1 of each keyframe of the animation and also save the time spent to reach each keyframe. Then, you would loop through each Motor6D of the character for each keyframe information and interpolate the character’s C0 and C1 that way.
This is what I do in my game that uses procedural animation, but I have only a few keyframes in my animations, making the process of recording keyframe information less complicated. I can just position a rig at each keyframe and use the command line each time to put the keyframe information in a folder.
Currently, regardless of whether or not Workspace.ClientAnimatorThrottling is enabled (at least for my experience, that part might be a bug), animators in WorldModels inside ViewportFrames are all being throttled as if they are far away.
Will there be any allowances made for ViewportFrames so that GUIs can still contain smooth animations? At the moment, I have no choice but to accept choppy animations in GUIs regardless of whether or not they cause performance problems (which they don’t seem to).
EDIT: After some further testing, I realised that the issue is likely unrelated to animation throttling, and is instead related to ViewportFrame refresh rates being decreased as more are visible, regardless of the amount of ViewportFrame’s that are actively updating (e.g 10 VFs with animated contents have the same refresh rate as 1VF with animated contents and 9VFs with stationary content).
Hi @FizzyFlame, we’re looking into this issue at the moment. Characters inside ViewportFrames shouldn’t throttle at all, so this seems to be a bug. I wasn’t able to repro this issue in Studio locally. Could you share more details on how you set up your ViewportFrame?
