This topic was automatically opened after 8 minutes.
Option 1 would be drastically easier to implement if animations weren’t cached after being updated for several days.
Very solid and understandable improvement lmo.
Thanks for keeping us informed while bettering the platform each and every day!
Without you guys we wouldn’t be, where we are today with this amazingly polished platform.
Glad to see some improvements coming to the animation engine! I love to see the performance upgrades, and it’s very nice to see instructions on how we can be prepared for these changes!
To clarify on what bugs are being fixed - are the minor bugs of keyframes with small time values not being sorted properly fixed, for instance? Or how animations use a custom tween-module instead of TweenService
? I know this may seem as if I’m just trying to bring the issues to light & get fixed, but I’m asking this because my game calculates the CFrame
a limb would be at during a specified TimePosition
, which has some very specific calculations - if the aforementioned animation bugs are fixed, my current code’s behavior would break, too.
Okay I see and appreciate the work that is being done to improve animation efficiency, but now we really need more animation priorities. Unless I’m misunderstanding this fix, you cannot stack animations well with just 4 priorities. We’ve asked for more animation priorities for years (Roblox should allow more than 4 priorities for animations) and with this removing the workaround we have been using it could break games.
Thank you for notifying us of some of these big changes.
Does this fix the issue of server animations not replicating themselves unless you’re near the assembley?
I feel like the change to the animation blending will show how limited the current AnimationTrack.Priority is, since there is only 4 options, a lot of animations end up sharing the same priority. I would love to see an update to this to change the priority to maybe be something similar to ZIndex
Will we see more animation priorities moving forward with this? This is by far our preferred method but animation-heavy games such as ours end up pushing the 4-priority limit, which stresses our ability to deploy animations in our projects in a clean and efficient manner.
Yes. We’ll need this for other upcoming features as well. It’s not final yet whether more Enum values will be added, or if Enum.AnimationPriority will be superseded by just an integer priority property.
I like this update and it seems great, but as some people are saying, we really do need more animation priorities to use this effectively! A game i’m developing on already stacks up with emotes, idles, walks etc at 4 priorities and then there are weapon swings and the likes on top of that. A suggestion I would adore in this would be if feasible to make the animation priority deter from Enum’s and have an actual integer as the priority, to allow developers to make many priorities of whatever they want with as many levels as they want.
Looking good, optimizations are great, though more priorities are definitely needed if possible.
This particular update does not change replication behavior, that is a whole separate set of changes that are upcoming as part of larger animation replication, throttling, LoD and sync updates.
im a little confused on what this means what was optimized?
The general memory (RAM) usage of animations was reduced for many devices, allowing the game to store more data for important things.
The performance for animations was also boosted for some devices, this means the game can run at higher FPSs and animations won’t lower FPS as much as before. (Which was not alot to begin with.)
Do all these new performance updates mean the playerscripts are going to be rewritten at some point?
I assume roblox wants to support more players in the server, which is going to be hard when the playerscripts aren’t that great, like how rbxcharacterscripts creates a stepped connection and unnecessary tables for every player, or just the general unnecessariness of most scripts
Correct. Animations are not commonly a bottleneck. Majority of the optimizations that I made to the low-level data structures and evaluators in the animation engine are not so much for immediate benefit, but to allow the system to scale more linearly to much higher player counts, higher part/bone counts in each avatar or NPC, and denser animation data. Mocap data is often fully dense, with a keyframe for every animated joint on every frame.
Awesome to see! I’m really excited to see the LOD feature for animations in the future. Does this system have anything to do with the “ClientAnimatorThrottling” property that was recently added to workspace, or is this completely different? If this is the same thing, do you have a date when would could get more news on that property?
I fully agree with this. We need way more animation priorities or just full control with the use of integer-based priorities (and fixing core having a priority of 1000 yet is the lowest priority, which makes no sense and just exists to complicate things for no reason).
Edit:
Oh, I didn’t see this reply yet…:
oh. ok i got it. sounds nice. might be useful for my game.