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)?
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.
instead of modifying the transform on step, why not first record the C0 / C1 at first and then modify them accordingly.
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.
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’m excited about this update! Thanks for this.
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.
YES! MORE PERFORMANCE UPDATES!!! I love it!
add whitelisting/blacklisting for lights to affect certain parts pretty please
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?
Yes, it is not actually a character set up in the Viewport Frame, that I am playing animations to. I am essentially rendering the character in the Viewport Frame by copying each part in their character’s CFrame to said Viewport Frame every RunService.HeartBeat. This mimics whatever they are doing into the Frame. So if they are being throttled (Turn your camera away from them), this is reflected in the Viewport Frame.
If for example they start to walk somewhere, this is reflected in the Viewport.
Doing it this way has many benefits, the obvious that it give you a lot more freedom and accuracy than if you were to try and copy each animation/movement coming from an NPC/Player to the Viewport Character.
Thanks for the follow-up, @FizzyFlame. We’ll look into adding ways to disable throttling per character/animator. This process can take a while, but in the short term there are a few workarounds:
-
@Proligant’s solution of interpolating the C0 and C1 CFrames of the
Motor6D
of your character. - If your character doesn’t have procedural animations, listening on the
AnimationPlayed
signal on the sourceAnimator
and playing the same animation on the viewportAnimator
should work.
Sounds good I’ll try those out, thanks!
Thank you guys, always love Performance Improvement update, I believe it will help Roblox metaverse graphics vision with 10k mass people in one event come true!
Hi @FizzyFlame. Check out the update to the post. We added a new property Animator.PreferLodEnabled
that should help you fix your original bug