Phasing out Workspace.ClientAnimatorThrottling

Hi Developers,

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.

95 Likes

This topic was automatically opened after 11 minutes.

I totally love this update, and I am excited about what you guys have in store for us for newer updates, especially regarding animations!

6 Likes

I continue bringing up this thread with these properties under Workspace

15 Likes

I didnt get most of that, im stupid
But i like how you cleared up the known issue

How much people would actually use it

2 Likes

It wasn’t clear to me. Is this performance improvement only for characters, or for any object (eg thousands of parts moving around in 3D space)?

2 Likes

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.

7 Likes

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.

8 Likes

instead of modifying the transform on step, why not first record the C0 / C1 at first and then modify them accordingly.

1 Like

Sometimes this may not be possible.

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.

1 Like

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.

1 Like

That’s correct! Thanks, @UnderMyWheel.

2 Likes

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!

10 Likes

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.

1 Like

I’m excited about this update! Thanks for this.

2 Likes

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.

11 Likes

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.

4 Likes

YES! MORE PERFORMANCE UPDATES!!! I love it! :heart:

add whitelisting/blacklisting for lights to affect certain parts pretty please :pray: :slight_smile: :slight_smile: :slight_smile:

4 Likes

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

4 Likes

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?

1 Like