AnimatorControllerOverride: ApplyOverrides WAY too expensive!

Right now, when a player equips a weapon, we override the animation it can play.

Our animator is about 300 animation. Currently, doing ApplyOverrides cost about 140ms, 40 of which is in Animator.SetupControllerDataSet, and the rest in ApplyOverrides itself.

Is there a way to change animation in an OverrideController without killing the framerate?

wow! That sounds like a coding issue for the Unity guys. I agree that 140ms is pretty bad unless its actually loading those animations or something. Otherwise it seems like my old Atari ST would get similar results LOL.

hi, which version of unity are you using?

we did fix a huge performance regression recently in ApplyOverrides, the system was wrongly sending a notify per clip rather than one for the batch, so if you changed 300 clips in a batch with ApplyOverrides it was sending 300 rebind to the animator … ouch!

2017.3.1

So… pretty much the latest “non-beta” version.

Managed to improve it by doing a diff of the previous list of animationclip and only pushing what actually changed… but equipping a sword is still 45-50 animations, which means 27-28 ms! Considering we are doing a 60 FPS game, that way above our 16 ms budget.


What makes Internal_SetClip so damn expensive??

since you are changing a clip we need to recompute the bindings for the controller, but rather than doing it only once for your batch of 50 clip, it does recompute the bindings after each set clip.

I will try to find out if this backport is landing soon in 2017.3

so it already fixed in 2017.3.1p3 and also in 2017.4.0f1

2 Likes

@Mecanim-Dev

We are using Unity 2020.3.11 LTS and it seem that this issue still happen, we are only sending an array of two elements to ApplyOverrides and sendNotification is doing 26ms spike for 6 NPC :hushed:


We also tried to use AnimatorControllerOverride[AnimationClip] directly but the result was nearly the same:

Does there is a regression about this? Could it be fixed? We are dependent on this for our new dynamic system and it’s a serious issue for us :frowning:

Thanks!

1 Like

@Mecanim-Dev definitely interested too in an update about that. Same issue with 2020.3 (and seen in a few versions prior to that, 2019 and such)

Hello @KospY , please can you let us know how many animations are in your controller and how many bones are in your rig?

Thanks!

1 Like

Our character have 68 bones, and our controller have around 212 animations (if I refer to the animator override controller). But we only send an array of 1 to 3 animations to change.

Hey guys I just sent a repro project for this (case 1353998).
On the example It show 40 ms spike for 10 npc, just by changing ONE clip.


Hopefully it’s a regression and will be fixed quickly.

That’s a rather large number of animations. Presumably it has to gather the bindings from every animation so I wouldn’t be surprised if the performance cost was directly proportional to the number of clips.

You might want to look into the Playables API or other animation systems that let you avoid needing massive Animator Controllers.

If we look at the third post from Unity, it seem that sending a notify should happen per batch and not per clip.
And the first guy have an issue with a controller with 300 animations, and Unity fixed that for 2017.
Anyway going over 100 animations is easy for any serious project, would be surprised if it's "by design".

Link to the issue: Unity Issue Tracker - Significant impact on performance when using Animator Override Controller

Thank you so much for finding and reporting this, they fixed it apparently! :)

Yeah that’s great! I’m updating right now to test and see if it work good now :slight_smile:

1 Like

This is still an active issue btw, we have it with 2021.3 LTS

It was fixed recently it seem!
https://issuetracker.unity3d.com/issues/significant-impact-on-performance-when-using-animator-override-controller
Crossing my fingers waiting 2021.3.17 release...

1 Like

Thanks for the heads up! We’ll definitely try this out

Before:

After:

So yes its better, but still an issue.