At the end of last year, we released a new property Workspace.ClientAnimatorThrottling to enable opt-in support for throttling animations. This week we released an internal update to our throttling algorithm. Our new technique aims to preserve visual quality for characters that occupy a larger share of screen space. In the gif below, you can see that the new throttler:
Preserves animation fidelity for larger characters, even when they’re further away
Decreases fidelity for smaller characters that are further away from the camera
Increases the fidelity of animations for characters that are closer to the camera
The new throttler is live now for all places with the Workspace.ClientAnimatorThrottling property enabled.
Coming soon
Opt-out phase
We plan on switching the Workspace.ClientAnimatorThrottling property from opt-in to opt-out in the next month. This is your chance to enable animation throttling in your place and report any issues to us before the switch. If you don’t want throttling, you can still disable this property in your place during the opt-out phase.
LOD for more animation components
In the near future, we also plan on incrementally releasing LOD implementation for more animation components. Expect more announcements soon!
Please keep us posted on how these changes affect your games. Your feedback is integral for the development of these features!
I’ve always loved the sheer chaos of that example gif. Can’t wait for additional avatar optimization/technology for quantities of this nature in the future. Awesome work on this.
If you notice in the new picture, the smaller character models are throttled to a lower fps. Looks like 2-3 frames per second. In the old picture, this isn’t exactly the case with it having a lot more FPS. I think the major improvement here is that it more accurately throttles animations based on distance + size.
If your game has a ton of animated NPCs for example, this would be ideal to use. Let’s say for example you had a town with walking NPCs or animated idle positions, this would work well and help manage performance on the client by throttling out any animations that are barely even visible to the player in question. It entirely depends on what type of game you intend on creating.
Wow this change looks amazing. Sorta off topic, but is there a reason that these behavior properties are still being added under workspace? The list of properties is growing and I’m just curious if it’ll ever get moved somewhere else? Maybe under a new service/settings tab?
Heyo, for the LoD in the future do you already have the option to disable throttling on specific models/AnimationControllers planned?
Due to this change, things like birds in the sky, butterflies and other decor controllers using animations are now abysmally throttled when either far away or on a smaller scale. I’ve had this option enabled since it first came out, before this change, and it appeared fine. Now however, a few players have reported the “laggy” decor changes to me thinking it was a bug.
Thanks for reporting this. Just for reference, what place are you using to test this? Looks like the throttling behavior of this bird is related to these updates. We’ll look into this and get back to you as soon as we have a fix.
We’re currently considering adding a property to disable throttling on specific Animators, but we’re first looking into making the throttler work generally without added properties.
Nil is correct. The new throttler’s performance in terms of FPS is roughly equivalent to the old one. However, the update ensures that characters that are closer to the camera, and occupy a larger screen space size, have smoother animations.
Hi BullfrogBait. That’s a great question/suggestion. For context, the throttling property was added in a previous update, not this one. To answer your question, place behavior properties that apply to the whole workspace will live inside the workspace for the foreseeable future…
Hi @Crab_Wrangler, thanks for your patience as we solve this issue! After testing locally with the asset you provided me, I can confirm that the locomotion of the bird is applied to the “body” bone of the the model, using a KeyframeSequence animation. This type of animation does not apply its transforms to the PrimaryPart of the bird.
Since the position of PrimaryPart is what’s used to calculate LODs, this can cause issues when the bird is on screen while the part is off screen. One quick work-around for you is to remove the keyframes from the body of the bird, and instead programmatically move the bird using its primary part. (looks like the bird simply moves in a circle, which you can easily do with sin/cos functions.
I created a test place with the same bird model and a “fly” animation with the locomotion removed. Instead, I programmatically added locomotion with the “Fly” script inside of the bird model. Check it out!
This is a temporary workaround, but thought this would serve as a good example for everyone on how to solve these types of throttling kinks in your places
