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!
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?
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.
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?
Thanks!
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)
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.
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.
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.
