We removed all our Animators and gained 30 FPS - [Alternatives to Mechanim]

I've been in charge of cleaning up a project that was performing extremely badly and what the Profiler identified as the worst offender was our Animators.

Our game is in 2D. All we are using mechanim for is changing frames of SpriteRenderers. The previous developer assumed that Unity's own system would be far superior to any ad hoc solution. And so did we. Whilst trying desperately to get the game up to 60 FPS in heavily animated areas we decided to try swapping out the Animators for a simple script like this:

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4.  
5. [RequireComponent(typeof(SpriteRenderer))]
6. public class Anim : MonoBehaviour {
7.  
8.     public Data data;
9.     public SpriteRenderer spriteRenderer;
10.     public bool playing = true;
11.     public bool looped = true;
12.     public float frame;
13.  
14.     private int f;
15.     private int totalFrames;
16.  
17.     // Use this for initialization
18.     void Start () {
19.         totalFrames = data.frames.Count;
20.         if(totalFrames == 0) playing = false;// sanity check
21.     }
22.  
23.     // Update is called once per frame
24.     void Update () {
25.         if(playing) {
26.             frame += Time.deltaTime * data.frameRate;
27.             if(frame >= totalFrames) {
28.                 frame -= totalFrames;
29.                 if(!looped) {
30.                     playing = false;
31.                     return;
32.                 }
33.             }
34.             if(f != (int)frame) {
35.                 f = (int)frame;
36.                 spriteRenderer.sprite = data.frames[f];
37.             }
38.         }
39.     }
40.  
41.     public void Play() {
42.         frame = 0;
43.         playing = true;
44.     }
45.  
46.     public void Play(Data data) {
47.         this.data = data;
48.         totalFrames = data.frames.Count;
49.         frame = 0;
50.         playing = true;
51.         if(totalFrames == 0) playing = false;// sanity check
52.     }
53.  
54.     [System.Serializable]
55.     public class Data {
56.         public List<Sprite> frames;
57.         public float frameRate = 8;
58.     }
59.  
60. }
61.  

Our FPS shot back up to 60.

So there's a serious problem with using Animator for 2D games. Certainly there could be more of a problem with the way we were using it. But just exchanging it for a script that called Update() every frame was far less expensive in CPU.

Are there ways to use Animator to bring it up to the speed of this script?

If there isn't then us 2D developers are stuck with this script. This version is simple and portable, but are there ways to improve it or have you created your own version. If we're not wrong and Animator is indeed terrible for 2D, could Unity give us a 2D version of Animator that we can use instead of writing our own?

 

What system was this running on? Also how many animators were active at any given time? I'm surprised that it hurt performance this badly.

 

The 30 FPS nightmare case was on Android (Moto G5S Plus), on Nintendo Switch we were losing 15-30 FPS. On PC this was much less noticeable but we were still losing frames.

Let me be clear in saying that the previous project lead had an extremely optimistic take on how many Animators a scene could support. We had a level that was broken into sub-rooms and despite only interacting with one sub-room at a time, the rest of the level was animating lots of things. It was a disaster scenario.

But even after doing all sorts of optimisation tricks, the only thing to restore our FPS to full was removing as many Animators as possible. (And replacing them with a script similar to the one above.)

I'm open to the possibility that Animator interacts negatively with the Profiler - but then this means it's impossible to do profiling accurately with Animators. All I know for sure is that what sat at the top of the Profiler was the Animator Director, and once I removed as many Animators as possible (especially for simple frame loops) we got a significant speed boost.

I will try to do some more research, but I wanted to start a discussion to see if others have had similar experiences.

 

Probably how you were using them to be honest, which you never talked about or showed. In general, using a manager or ECS would reduce the time taken even further.

Can you show the code you were using to interact with all those animators?

 

This was covered in Unite Berlin 2018 best practices. Summary: only choose an Animator over an Animation component or a simple script if you need its extra features.

 

If you have a lot of those scripts active at the same time, this blog post could be interesting:
https://blogs.unity3d.com/2015/12/23/1k-update-calls/

I have a "Billboard" Component on a lot of GameObject's and not implementing Update(), but having a dedicated manager that calls "Update" for me on those Billboards, just like the blog post describes, caused a nice performance improvement as well.

It's probably something the new C# Job System can do even better.

 

Why would you think that complex beast that is mecanim would perform better than manually stepping though a sprite frame by frame? I mean you can go further (e.g. animating in the shader), but what you have is basically the raw instructions for animating.

That said you don't mention how many animations you have, I've never seen any problem with 20-30 mecanim animations on screen even on low end platforms. Imagine something like an RTS would be a different story...

 

We had in excess of 100 animations. In a 2D game this is quite normal for us, there are many animated background elements, bespoke particles, various enemies, etc. Our studio is famed for detailed pixel art and animation.

Why would I use Unity when I could write my own engine in C++? Why would I think that Unity could do a better job of animation than I?

 

Many of them weren't interacting. Just simple animation loops. No code. Otherwise the script I posted would have been of no use - note that the script just plays a loop of frames. It accepts an Anim.Data, but that wasn't what gave us our FPS back.

 

Is that guy in the video official Unity staff?

At some point he says "let me dispel a rumour now, you should not be afraid to use the legacy animation system"

Oh, really? Because all communication from Unity seems to be to stay away from the animation system. (even the manual)

And even more annoyingly, they have been refusing to fix bugs for it (bugs, btw, that they introduced when mecanim first arrived), because it's legacy and not supported any more.

And now they decided that LOL JK if you care about performance, use the legacy stuff?

Are you kidding me?

Remove legacy from the title, update your manuals and support the thing then.

It's not a rumour, ALL your communication suggests that we should move on from the Legacy Animation component, you CAN NOT remember it exists and actually suggest it to people only when we complain about how terrible the Animator is, but otherwise treat it like it doesn't exist.

Edit: I guess the last line wasn’t really needed.

 

Yes. Like the video mentions he's the lead developer relations engineer for Unity. He's on the enterprise support team.

 

Can we submit bug reports for Unite talks?

Because somehow these statements, all from Unity, are not compatible

(emphasis on yet)

So, which is it?

 

The guy is Ian Dundore.of Unity. What he is says it that the old Animation component is for simple cases much faster than Mecanim and should be used for that tasks (esp. when you work for a mobile app). This is at odds with statement by the Unity documentation.

 

No yeah, I figured it out, it's in a quantum state of being Legacy. It depends on the observer.

If you ask for a bug fix "Nah, it's legacy, use Mecanim!"

And then after many days/months of work to transition to Mecanim If you complain that Mecanim is slow, magically the animation component is not Legacy any more and I should have been using it the whole time!

Ah, science.

 

I consider the advice about legacy to be terrible so I'll just be polite and stop here:

1. If it's legacy don't use it
2. if it's depreciated don't use it

If Unity intends us to keep using something, don't mark it as legacy. Wake up.

OK cool. Because typically people use Play to play a state on an animator and there's a fast and slow way of doing that.

Animator is overkill for simple things. It's designed for handling huge jobs, large rigs. It's not designed for doing hundreds of tiny jobs. It's designed to scale well for hundreds of hard jobs due to the initial overhead.

Also, you should use a manager class instead of individual updates to shave more time off. You just basically fell into the Unity trap where learn materials or videos will suggest the easiest and non-optimal way to achieve something. This is usually going to be the best advice for most of Unity's non professional or hobbyist customers.

 

Actually I am a huge grump and used to avoid using any of Unity's solutions. It was the previous project lead that had a ridiculously optimistic view that anything Unity made "shouldn't be a problem". Nowadays I try to take a hybrid approach and use features or re-write those features with pragmatism being the main goal.

And yes, my script using Update() is bad form. What's surprising is that you can have 100s of said scripts, all calling Update() and they're still faster than Animator. When you're doing emergency optimisation, it's a great solution.

I would however love to see a more thought-out 2D-Animation system. One that can register itself with a manager to deal with the Update() problem, I invite people to propose solutions.

 

Like me then. I'm a massive grump at most things. However, Unity's Animator is ridiculously well optimised for what it should be used for, and it's original design: dealing with ambitious and complex rigs and blending. That's all multi threaded but there is an initial cost that's probably more than the 100s of minor rotations or lerps you'd want to do, so it's more about tools for job.

Here, you used a tank to drive to the supermarket. I don't think that's your fault though.

 

I think neither blindly use anything "canonical" for everything nor the "don't use anything from them"-approach are right. I think the right thing to do is to read/watch/investigate as much as you can regarding the tools you want to use and make your own decisions.

Ian Dundore is one of the Unity guys who stand on the stage and reliably critical to their own work. All the time. It worth your time to watch all of his presentations about various aspects of Unity.
But as he always says: trust no one and accept performance advice from no one (even from him, although he and his team do a great job), make your own measurement.

 

This isn't really about performance.

It's more about, if you want us to be using something, don't put "Legacy" in front of it. Call it something else and stand behind it.

And I really hate that Unity keeps insisting that they don't have a gap in their animation feature set. First it was "Mecanim is close enough" in terms of performance (it wasn't). Then it was "what gap? we have the legacy animation, which is awesome btw".

I remember being excited when they released the Simple Animation component. But it wasn't fast. And the dev said on the matter:

It's not the point, huh?

So dear Unity.

Should I be using Legacy Animation?

If yes, why is it called Legacy?

If not, what can I use for simple animations that performs almost equally fast?

This issue has been going on for years.

 

So, it would be way overkill for say... a button?

 

Mecanim is bloaty for simple tasks. If you have simple animation tasks then you can 1) use Legacy, 2) roll your own or 3) accept the bloat for your simple task.

I think it would be prudent to offer a simplified Animator for basic things like UI and 2D stuff. Mecanim is otherwise pretty great at what it's intended for.

 

He spoke in performance context, so it's about performance.

One thing you always forget when you rant against Unity: they are serving a ton of people all shapes and sizes. What is the best for you isn't best for others. When they say that Mechanim is the way to go, they're speaking >>>in general<<<. They don't talk about you. They talk about in general.
And in general, mechanim is the way to go (or playables, or whatever you find best fit for your problem).

Can you find the animation component in the current Unity you're using for your product? Yes. Can you use it? Yes. End of story, does not matter if it's considered outdated by Unity. You're not supposed to upgrade unity mid-development, so you shouldn't have any problems if they actually deprecate it in a future version.

Use whatever fits to your problem.

 

Part of the problem with this though, is that when it was considered legacy, it stopped getting some updates. There was an issue early on with the animation component not being able to access certain new things (if I recall correctly it was something in the material property block). The official response was that since it was being phased out, the solution is to move to animator. I don't know if that has changed or updated, but as per Unity's recommendation, we moved over animators which solved the problem. (this was a couple of years ago). Legacy means (or usually means), that it won't get updates beyond critical bug fixes and won't necessarily play nice with newer features.

 

I would think DOTween or something like that would be pretty cool...

 

Yes.

Since I use Unity I ask Unity to help me to create my stuff, one thing I wouldn't ask Unity to make the decision for me what kind of tools I should use for what problems.
If animation fits the bill, I will use that (and if it's available in a given version), if it does not fit (for whatever reason, for example because it does not support XYZ shiny new feature), I would look for another solution.
But it's not Unity's job to decide the tool. It's ours, developers', because we're solely responsible for our product at the end.

We can ask Unity to create a tool which fits for XYZ problem, we can ask them to not deprecate a tool, because we find it better, but in this thread, it's not about that. It's a story of a product where the original creator flown blind and didn't do his or her homework. He just started to use a tool without deeper knowledge.

I think this is the problem, not that Ian Dundore says if you have performance problems and you want to animate some small pixels on the screen you should consider using the legacy animation.

 

It is, but it isn't simple, or clean. I agree that Animator is best intended and used for large complex thing, and is quite good at it. But for simple things like buttons it is overkill.... yet, that is the built in solution. If you want to simply scale a button, Unity creates the animator and anims and wires it. Which is actually a pretty significant performance hit. (animators always animate, you have a simple button on a canvas with a animator, that canvas is redrawn every frame, for no good reason). The button states aren't adequately exposed, meaning you have to extend the base button class, and connect other actions to the states (which aren't simply exposed). Certainly it is doable, but it isn't clean, supported or well thought out, everything is built around using the animator.

I seems to me that what happened is that the Animator was originally intended to be "the" animation solution, big or small. Over time though, it has become more specialized and gained a lot more functionality. For that purpose, it is great at what it does. But now it isn't practical for simple stuff, and the animation component has seen enough love to be clean solution either. I feel they should "un"-legacy the animation component and bring it up to date and clean it up. Or replace it with a new one that serves the same purpose.

 

Being a programmer my immediate thought was towards scripting too. I would make a collection of scripts that perform a single effect with events that trigger when they've started, stopped, at a configurable interval, etc to chain them.

 

The problem though, is there no longer is a simple animation solution (that is supported and up to date, or not likely to disappear in future versions). Also it wasn't about supporting new features, it was about supporting changes to existing features, when how materials were handled was changed, it broke animating textures. While I can see this being a valid argument for many, many things that people want, it's not for animation. Animation is pretty critical to a video game engine. It Unity were a board game engine, maybe not so much.

 

I agree, it would be great if Unity would revoke the 'deprecated' tag from the Animation and they would support it, or at least write a better solution for us. But the original argument wasn't about this. It was about if Unity were in the wrong to tell that in general, you should use the Animator.

And on the top of that, this thread is not even about that. It's about what they can use instead of the Animator right now.

They can use animation, tween solutions or they can write their own.

 

As older versions of Unity tend to not be able to build for newer Mobile OS' (because new requirements pop up), that is very, very wrong. But thank you for making wrong assumptions.

Actually, No. I can't. But thank you for making wrong assumptions. It has bugs and lacks features that are more or less necessary by now. When I filed bug reports Unity said, it's legacy, use Mecanim.

And somehow asking them to either properly support the legacy animation, or introduce something new that fills that hole, makes Unity less capable of serving a ton of people of all shapes and sizes? I don't get you.

No it's not. It's really the way to go for humanoids and complex rigs. For anything else it's overkill.

 

No, you don't get me, because you don't make distinction between asking them to support something and calling them out on a performance advice.

In other words, this is what I'm arguing:

Because it's not. The guy was talking about performance, he stated (he actually measured), that for small things, certain UI elements Animation is better from performance stand point.

And you jumped on it and generalized it. This was the thing I called out. Otherwise I agree, Unity can do a better job to support animation in general. And I believe they will, probably they will write something on the top of the ECS-Job System as soon as they have the resources and somewhat finished these base layers. But again, this should not be the subject of this thread.

 

I think you don't get me either. It was performance advice but that wasn't what I was annoyed about and called scummy. (which in retrospect is maybe an overreaction, but not big enough for me to go back and edit that post)

(Edit: in retro-retrospect I think editing it out is worth the effort, so I just did that)

It was the "let me dispel a rumour now, you should not be afraid to use the legacy animation system" that annoyed me. More specifically the "rumour" part, because it implies that it's something we the user base came up on our own and it wasn't their consistent messaging for years now that "legacy is done, move to animator".

Like:

-"Hey Unity, I want to use legacy, but it doesn't work with materials any more"
-"Legacy is done, move to animator"
-"But animator is not as fast for our use cases"
-"Legacy is done, move to animator"
-"Okay, but you're going to make it faster at some point for simple stuff, right? I mean we animate a lot of buttons and doors opening and fans rotating, slow texture panning, simple color changes etc"
-"Animator is the future"
-"Well, okay then"

And now I see Unity saying:

-"You know what's cool about Unity? Legacy Animation, man I love that stuff, it's so fast and sleek. I have no idea who is spreading these bizarre rumours that we're going to remove it! We never said anything like that, we just called it Legacy because we thought it sounded cool. Please go ahead and use it, it's an important part of your toolbox!"

(obviously exaggerating to try and explain how it feels to me)

 

The subject of the thread is animation options and unity's messaging in that regard.

"scummy" definitely is the not right choice of words, but the point is valid. Unity has, at least, a messaging issue, at most, a feature clarity issue.

I tend to take docs and marketing with a grain of salt, often the are targeted for those other than professional developers. But I do listen to what staff (developers) say and recommend and the test and gauge appropriately. Often the valuable info comes from folks like superpig, ian and others. And sometimes that does conflict or contradict the official line. And that is fine for the most part, just wish they were on the same page more often.

 

I actually did a bug report for the docs.

This the reply I got

So animation will stick around. Not sure if it’s going to lose its legacy status. I think it should.

 

@zombiegorilla - What tool's that screenshot from? Looks like a nice interface.

I like the Animator as a state machine; in fact, we're using it as one in several places that aren't even animation specific. But indeed, for something like a simple effect it can be unwieldy - not only for performance, but for being able to find things easily.

 

It from a tool (set of tools really), that I built about a couple of months ago. The idea was to replace animators in the UI with programatic solutions based on DOTween. (also they handle buttons and arbitrary mesh rendering to canvas). Our performance wasn't horrible, but moving to this method was a vast improvement over using animators.

 

Good to hear.

 

Just throwing this out there... renaming to "Lightweight Animator" and "Complex Animator" or something like that would be a great idea on two fronts.

For starters, yeah, if something is "legacy" then they shouldn't be proposing it as a solution to stuff after the solution to other issues was "move to the new thing".

Secondly, the naming is terrible in the editor! I don't use animations a heck of a lot in my current, long running project because we just don't really have to. When I do, I need to arbitrarily remember whether it's "Animator" or "Animation" that I want... neither of which are meaningfully distinct from one another as names.

Far out... there's stuff in my current project that I would quite possibly have done differently if I knew that. Thanks for sharing, @AcidArrow!

 

What about this thing?
https://blogs.unity3d.com/2017/11/28/introducing-the-simple-animation-component/

Although really I'd just code what I want with some math tweens. How many throbs does a button need anyway?

 

That goes right back to the performance issues that started this conversation. From the 5th comment on that post:

 

It still uses the animator. Probably fine in some cases, but a problem for ui.

 

Yeah this drives me insane too. I don't often dive into animation, but when I do it always starts off with half an hour of trying to figure out which of the similarly named components was which. Its no issue if you spend all your time with animation. But its one of the most jarring parts of the Unity workflow if you just dabble.

 

Isn't "animation" component supposed to be deprecated?

 

Back to the OP's question, some ideas as further questions:

1. Would Delegates be a good pattern for having 100's of animated objects "subscribe" and "unsubscribe" to a tick? Kind of like building one's own animation system within the Unity engine...

2. ECS/Jobs are good/great at looping, would it be possible to make a system (the S part of ECS) that goes over entities (characters) that have Components which need animating, wherein they register to be a part of the system based on culling or other criteria?

To the OP, thank you!!! I'm loading up Animators, after having spent enough time to figure them out, and will now roll back on that.

 

Apparently not anymore.

 

I agree with the sentence you deleted.

And would like to add:

Why is it that this obscure, barely viewed and unsurfaced video, also features the only information I've seen about this?

Animator.keepControllerStateOnDisable

 

Stellar is the only word for this. Well done.

 

Anyone know how to edit an Animation after it's been made into a legacy Animation? I can't seem to do it. Converted a Mecanim Animation to Legacy. Left the Animator on the Object. Added an Animation Component. Engaged it with script, no problem. Can pause, rewind, set to time = 0, play. etc. But... can't now edit its timeline.

 

Maybe remove the Animator?

-Remove Animator from gameobject.
-Convert clip to legacy (go to debug)
-Add Animation Component.
-Animations Size to 1, add clip there.

Then you should be able to edit the clip in the Animation window.

There were some limitations and issues a long time ago, mainly with materials, not sure if they're still around.