Mechanim = pain

I have been developing games professionally since the 90’s and with Unity for about 3 years now and I have shipped a big commercial title with it.

For the past month I have been banging my head against Mechanim, it has easily been the most frustrating experience I have ever had in my career. I estimate that cumulatively I have spent about 6-8 months battling Mechanim in the past few years. Previous to this we had our own in house engine. The animation system had about 50% of the core features of Mechanim, it was sufficient and I wrote the whole thing in about 4 weeks.

To give you some reference I am just making a fairly straight forward FPS, but with the animation fidelity that you see in modern AAA shooters. The characters don’t do anything special like parkour around things, just walk, strafe and turn.

Without any further ado, enter the rant…

Design problems with Mechanim

1. You have to use it, and there is no low level API. The best way this could have been implemented is to have something like the legacy system, then Mechanim to sit on top of that. In this way you could still do things like just load a clip and play it on a model without having to make an Animation Controller and a State graph to do simple things. The blends could all be accessible to the user allowing people to make their own Mechanim type systems. Funny thing is that Unity already has this, it is the “Legacy” system that worked fine for many people but now there is the looming threat that it will be taken away at any time.

2. State Machines are not the best solution for everything. The problem is that if you do anything even relatively complicated with them they it ends up being this big spiderweb mess. They are hard to read, unnecessarily complicated vs some code that does the same thing, hard to debug, hard to difference, hard to copy paste, hard to reuse functionality. Toss this in with the instability and idiosyncrasies of the editor and it is a nightmare. I can’t tell you how many times I have spent an hour or two working through some gnarly graph just to have unity crash and loose everything I have done, or it just not save for some reason. Or the hours I have spent dragging and dropping fields over and over or recreating deeply nested blendtrees because of having to deal with a visual editor. The idea here I think is that it makes it more accessible to people like artists. However, it hasn’t been my experience, it is so hard to manage these complicated things that all the artists I have worked with end up just handing me clips to plug in. At some point I had the idea of just setting up a bunch of unconnected states that I can call in the code, so I can reduce these graphs down to 50-100 lines of very simple easily debugged code. However, I am still required to drag drop every animation clip into some slot somewhere, adding another level of unnecessary abstract, a place for potential bugs, and another step for adding content.

3. Mechanim’s behavior is unpredictable, and when there are problems it is almost impossible to find them, and if they end up inside of Mechanim the chances they will get fixed is virtually none, and there is no work around. The blend modes are super esoteric and there is no real documentation about what they are doing, they do this strange mixture of blending weights and speeds at the same time. Take an animation of a guy walking put it on a 1D blend from speeds -1 to 1 with the same blend values. At .5 you would expect the guy to walk half as fast right? Nope…. In fact, modifying the speeds or even knowing the speeds that animations are playing is virtually impossible. For the past week we have been trying to figure out why just changing the speed param on a state makes our character explode into 100x its size and crash Untiy 5.4 completely. Or why moving this state speed around doesn’t seem to change animations that are already playing. It is hard to separate what is intended behavior from what is unity bugs.

4. It doesn’t scale. Okay so I am making an FPS let’s say I have 50 guns, each has a suite of animations, you know Take out, Shoot, Reload… They all work the same there is just different animation for each one of these. If I follow the Mechanim way I would have to make 50 nearly identical state graphs. Now I find a bug in my logic and I have to make a change to the graph, now I am editing 50 of these. In the past we would just have artists drop predictably named animations into a folder and we would load them and drop them into our logic. So now the flow I need to tell them is. “Crack open the playerController, open up layer 3, sub state guns, copy and paste one of the states make sure all the transitions are hooked up etc.) You know who is going to end up doing all this “work”? I am… I thought I would get cute and use the override controller to correct this however changing the override controller resets the state and of the animator and makes horrible things happen. (Which I believe is part of the source of the crash in point 3). It isn’t surprising anything that seems to be just outside of what you would do in one of the demos, tends to have problems. It is unfortunate if you are trying to make something that is different or has more depth than Angry Bots.


There is also this whole load of things that are obviously bugs with the system, despite it being the only accepted animation system in the tool for years now. So many of these come from some complicated cases and don’t always cause crashes, I wouldn’t even begin to think about how to report them. Even if I did in the past when I have done this with really simple and reproducible problems the turnaround time for fixing things has been several months. Although new features seem to keep appearing in the engine every few weeks. It is obvious where resources are being spent. Honestly I don’t blame Unity for this, it is a very complicated tool. That is why having a simpler and lower level API to access this is important, at least then I could build up a system that works for me and I could have the burden of maintaining.


Anyways I am going to get back to work here. Just before writing this I was experimenting with our player animation controller trying to figure out to play an animation with a predicable speed. I thought about making a 1D blend like described earlier but putting an identical motion every .1 on the blend to mitigate the weird speed problems. As I dragged the same clip the 5th time out of the 40 or so I will need. The editor crashed to desktop, when I reloaded the project the last 2 hours of work was gone. I figured I would take a break. I don’t know what I am expecting to get out of this rant, my only hope is that someone at Unity will read this without getting personally offended and maybe consider making the legacy animation system an important part of Unity again.


//endrant

 

Yeah, it's pretty bad!

There's also the fundamental problem of the Animator Controller defining a set of states. Not only in the state nodes and their transitions, but also through the current state of all the bools, ints and floats.

At the same time, your MonoBehaviours and components on the same object have defined their own state. Keeping those two states in sync is a nightmare. If two triggers gets set on the same frame, it will probably break the animator, with one of the triggers sticking around and kicking in a minute later. We've had so many bugs with that.

And don't get me started on the travesty that's the StateMachineBehaviours. Such a good concept, such a completely useless implementation.

The only good features in Mechanim that the old Animation system lacked are the ability to preview and adjust transitions between animations, and the ability to easily blend between movement states based on a float. Everything else is just a very difficult way to ask the system to play the animation that matches the state of my scripts.


At last Unite, the dude talking about animations QA session mentioned that they wanted to give us access to just playing a clip on an Animator, instead of having to set up a state machine. That would be an immense improvement. If we can get access to the API that's used to play animations in the preview window, and a proper set of "crossfade to this animation" API calls, making a custom layer that's easier to use then Mechanim should be pretty easy.


EDIT: Oh, and the quality of life problems are also staggering. The worst one is that any click in the animator window will set the animator controller as the current selected object. So if you have the model you're dragging animations from open in the project view, and click a state, the project view jumps to the folder the controller is in. I always forget to lock the project overview, and it's aggravating! Who thought that was a good idea?

 

Hi DDNA,

We are sorry to hear that you are struggling with Mecanim.

First, Legacy won't be removed until Mecanim cover all the users case, we know that simple case are easier to handle with legacy so we have one dev and one designer currently working on this.

If you don't like the visual editor to edit your controller you can always create your controller from script
http://docs.unity3d.com/ScriptReference/Animations.AnimatorController.html

For the override controller reseting the whole animation, the bug was fixed in 5.4.

We agree that statemachine are not the best solution for everything, but one the goal was to give some control to artist that don't know how to write script but still have some technical knowledge. You may not like it but there is a lot of artist out there that are pretty happy to create their own animation logic.

If you prefer this way of working that great, you could write an editor script that add your animation clip directly into your controller with a script based on the file path in your project folder. By example all clip in folder enemy could be directly added in your enemy's controller.

I do not agree, the animation team is always working pretty hard on bug, our bug count is one of the lowest in unity. If you don't log your bug there is a high chance that it won't be fixed if we are not aware of. If you are not sure if a behaviour is a bug or not don't be afraid to ask it on the forum or log a bug. We are 5 devs working full time on animation, and there is always at least two devs working on bug fixing and each two weeks we do a full week of bug bash all the 5 of us. So the work power is 60% on bug and 40% on new features.
So if you take the time to log your bug with a good repro and a good project there is a high chance that it will be fixed really fast.

I did look at your profile and since last november you did ask two questions related to mecanim but nothing related to undesired behaviour or bug so it pretty hard for us to help you if we are not aware of your issues.

Yes mecanim is complex and there is some corner case but keep in mind that we must support thousand and thousand of different user case from Ubisoft assasin creed identity to candy crush.

Speak up, we are listenning
Best regards

 

My apologies for going off a rant here. I really appreciate taking the time to respond. Let me try to respond as best as possible to the comments. But before I do this let me explain the immediate problems I am facing.

I have this really complicated blend tree, for locomotion of our character. The character has a walk strafe and turn animation. Based on the physics based movement that the character is doing. I am adjusting blends and speeds so that the character tracks the ground.

On top of this, the character can hold lots of weapons, more than I would like to setup states for. So I have one state graph and I use the Override controller to swap out the clips for the upper body at an opportune time.

I have tried this a few different ways and I have set this up in a way that seems reasonable to me. Basically there is a blend tree that is blending between the walk strafe and turn animations, and I use the speed parameter on the state to adjust the speed of the final animation. In this way I can setup the blend to what it needs to be and based on the physics I can tailor the character animation to the right speed so it tracks the ground.

When I changed the speed parameter at certain times. It seems to be during a state transition, the character picks up an enormous scale from nowhere. We updated to 5.4 and this would completely crash unity. So 3 of us for 3 days tried to distill this down. I found that this was related to changing the speed on the state when we were using the override controller. If I removed the override controller, it wouldn't get the scale, but the animation still seemed to get stuck in a state. It was as if changing the speed parameter didn't change the speed of the existing animation but would only alter the speed of the next clip that played.

Here is an example of what I am seeing.

I would love to send this over to you, but it is a multi-gig project. I figured you would want a simpler repro case, so I spent an afternoon trying to build one in an empty project but I wasn't successful. At day 4 of working on this I felt I probably should peruse other solutions. If you want me to deliver you the entire project so you can look at this I am fine with it, email me tom@digitaldnagames.com and let me know how you want to do this.

 

Now for some of the more general issues.

Crossfade:

Yes I know about this and use it almost exclusively. There are some idiosyncrasies. For example if you call it then immediately ask the animator what State are you playing, it doesn't work. The changes doesn't happen until you advance time. Also how about play this clip at 2x speed, this is such a common thing to do, but is so difficult. Or for that matter ask a state how long it going to play, or ask the animation for a list of states. I did not know that you could add states to the graph dynamically at runtime, I guess I would like to know more about that. Can I build a blendtree at runtime?

I guess my question to you would be given my situation. 50 suites of animations that share the same graph structure, how should I organize this data in unity?

Bug Reports:

I don't want to hammer you on this you are being very helpful, and to be fair the bugs I have registered in the past have not been animation bugs. Typically animation bugs are so hard to isolate that I haven't been able to build very simple repro cases for these, so I don't report them. Then some of them like the Override controllers resetting everything, have been around for so long and are so well documented there isn't much to do vs approach things in a different way. Although with other issues I have went through the trouble of isolating and building very clean repro cases for the result have been discouraging, I will just leave it at that. When you are doing this in a professional environment it isn't really an option to wait 6-8 months for a breaking bug to be fixed, which is more inline with the experience I have had. But this is understandable because your team isn't there to service me. That is why being able to access the animation on a low level is important, by now I would have implemented my own system and I wouldn't be writing this post.

Blend modes:

Okay maybe there is something I don't understand here, if I setup a 1D blend like this.

Walk(Speed = -1) --------------------------------------------------------------- Walk (Speed=1)


What speed will the walk be at .5? My guess would be .5 although that doesn't seem to be the case.

I have seen a lot of demos where you put some values close to 0. Here is an example of that? Where is the point on the blend where they speed is .5?

I can stick an Idle animation at 0. Which is a little odd because I don't ever really want a Gait that is a mix between idle and walk, but again where is speed .5? The result is bizarre like you would expect.

The 2D blends are just more complicated examples of this. If I can't get this simple one to behave I have no chance with the 2D ones. This is a good example of what I mean when I talk about it being unpredictable.

I just want to play animation x at y speed, and eventually blend it with another animation playing at the same speed, and I would like to know what speed the animation is playing at so I can predict how far the guy will travel. This is actually a really simple scenario. Animation X and Z played at Speed Y, then blended with X*Blend+Z*(1-Blend). How do I do this with the API? I can't even seem to do this with the editor.

The problem is the API isn't an animation API that Mechanim is also consuming. It is an API to high level abstraction which is Mechanim. Ideally I should be able to build something like Mechanim myself, the API that exists isn't capable of this. By this point I would have just wrote some system myself that did what I needed, instead I am scratching my head trying to decipher how Mechanim works, so I can do the most basic of things.

 

In which version of unity are you working right now? it will help us to help you

 

5.3.6p1

We updated to 5.4 but the bug in the first video completely crashes unity so we had to roll back.

 

Could you make that official in some way? The impression going around the community is definitely "Animation is deprecated and could be killed off any day now, so never use it". We want to use it - for things like opening a door where an animator controller is ridiculous - but we can't as long as it's in this limbo state where we're worried that we'll have to stop upgrading or redo a bunch of the project if we do.

 

@Baste As we already said, Legacy will stay until Mecanim cover most functionnality used by users. Also we want to make sure that the switch from Legacy to Mecanim will be painless, so we will create an API that is really close to Legacy.

 

Yeah I think there is something you didn't understood.
First Animation clips in blend tree need to be synchronized, if they are not sync the result will be S***.
By synchronized motion I mean that at time 0 all clip must start on the same feet, let say left feet, at 0.5 all clip must be on the right foot and at 1 all clip must be again on the left foot to loop the motion.
Of course here the time is expressed in normalized time, animation clips in a blend does'nt need to have the same length to work, the blend tree is handling all this for you by changing the speed of playback to match all clips. Of course you will get better result if all clips are of the same length because the original speed from the clip will be respected.

For this simple case I would not use a 1d blend tree but rather a state with a speed multiplier that you can change with a controller parameter's, take a look at this package

 

I did another test with a 1d blend tree like you did so you can see the difference between a blend tree and a simple state with as speed multiplier.

In this case you can see that the blend tree doesn't change the gait of the two motion which is normal because the blend tree is doing a linear blend between two motion with the same gait, but the average speed of both blended motion is affected because we are blending two root motion: by exemple 1 meter/sec and -1 meter/sec.

At 0 you can see that the blended gait isn't affected but the blended root motion speed is now 0 meter/sec

 

I was definitely confused because I have seen so many examples setup in the ways that I illustrated in the example. i.e. an idle animation in the middle, or a time scaled animation half way on the range.

In the end since I wanted a 3 way blend I ended up with something that looked like this.



Where walk is in the middle and Strafe and turn are the extents. Then I would control the speed and direction with the parameter. This is actually how it is setup in the project that I sent you. However this is where I ran into the bug where the guy was exploding. So maybe I was doing the right thing and I was just running into a bug. I started to play with the 1D blends because it was an alternative to using the speed param which was causing me problems.

I never really looked at the legacy system much before. When I did I was astonished that it did so much. Between being able to setup the clips in code along with being able to setup the blends in code to, it seems perfect. I think I may just transition to it, because it solves so many of my problems.

I am a little worried however that I will just run into the same bug. Do they share the same underlying code?

 

nope both code path are completly different, mecanim was integrated later in Unity 4.0 as a 3rd party animation middleware

 

@Mecanim-Dev: I tried your example (with the 1d blend) and it works as long as root motion for translation is checked. If you uncheck that (as you might if your character was driven by physics) the animations don't blend at all.

 

@Tyrathect : This is expected since your are setting up the animator to not handle root motion, in this case the root motion is sitll blended but you must handle it in a script. Here a simple example that use the blended delta root motion from the animator, but of course you can add some physic stuff inside this function to handle your specific need.

Code (CSharp):

1.    
2.     void OnAnimatorMove()
3.     {
4.         Animator animator = GetComponent<Animator>();
5.         if (animator)
6.         {
7.             Vector3 newPosition = transform.position;
8.             Quaternion newRotation = transform.rotation;
9.             newPosition += animator.deltaPosition;
10.             newRotation *= animator.deltaRotation;
11.             transform.position = newPosition;
12.             transform.rotation = newRotation;
13.         }
14.     }

 

@Mecanim-Dev: Thanks, but what I meant was that the animation speed doesn't change (the legs don't slow down)

Please try the following:

1. Uncheck root motion for translation on the animation
2. Start the animation preview
3. Scrub the speed parameter (slowly move it around)
4. Note that the animation doesn't change.

The "speed" setting in the blend keys seems to be ignored if the animation doesn't have root motion turned on.

This is not the same bug as the blow-up DDNA is talking about, it seems to be another issue.

 

So after some more testing I realize one of the problems that I am having is that the Crossfade is affected by the speed of the animation. i..e. if you do a 1 sec crossfade and the speed of the source animation is .1 it will really be 10sec. I assume this is what CrossFadeInFixedTime is for.

 

@DDNA yes you right, transition timing by defaut is in normalized time based on the state starting the transition.
If you want time precision please use CrossFadeInFixedTime/PlayInFixedTime.

 

yes this is expected since we are blending two identical motion, with a blend weight at 0 for this blend tree we are blending 50% motion Walk + 50% motion walk, the only difference between both motion in this case is the average speed on the root motion, first one is 1 meter/sec and the other one -1 meter/sec, that why when you move the slider you see an impact on the root motion but none on the gait of the character.

 

So you're telling me that I can't smoothly change animation speeds using mecanim unless I also use root motion? And that seems okay to you?

This is a crippling limitation! It means you can't use mecanim with the character controller. How would I keep the feet from sliding?

This doesn't make any sense at all!

 

that not what I said, I said in this case this is expected since your blending the same motion twice

But if you put a motion that run and another that walk then blending between both motion will give you the impression to blend the speed of both motion.

 

But I'm limited to one walk speed and one run speed. I can't scale the animation rate so the feet will slide unless the character is moving at exactly the rate of the animation.

The fact that rate scaling works if you're using root motion, and that you can scale any animation in the legacy code shows that you guys must have some idea that it's useful.

Let's say i want to make a game where a guy rows a boat. The boat's motion is driven by physics but I want the guy in the boat to route faster as you accelerate. You're saying that I can't do this with mecanim (the animation system you're pushing) unless I author rowing animations at multiple speeds. Nice. That's sure easy.

 

Well that not exactly true because we do have a IK feet stabilizer just for this case.

true, you need at last two motion, the slowest one and the fastest one to give you the range of available motion for your character. As you add more motion in your blend tree you are increasing motion fidelity but decreasing the performance.

 

Having done a lot with IK, I can tell you that you can't use IK to change the gate. You can use it to ensure the feet are on the ground, but you can't use it to make a walk animation slower.

Also, there is no documentation for IK Feet stabilization beyond the one sentence declaration that the stabilizeFeet property of the animator stabilizes the feet:

http://docs.unity3d.com/412/Documentation/ScriptReference/Animator-stabilizeFeet.html

There's no discussion about requirements or expected results.

Finally, based on the following threads, I'd say that most people would be surprised to find that Mecanim won't honor time scaling unless root motion is enabled:

http://forum.unity3d.com/threads/pr...r-from-maya-to-unity-using-legacy-rig.308991/
http://answers.unity3d.com/questions/913840/can-i-change-animation-speed-with-mecanim.html
http://forum.unity3d.com/threads/me...speed-of-specific-animation-or-layers.160395/

Okay, I'm beating a dead horse at this point. I know you're trying to be helpful, but explaining how I should make three right turns (authoring multiple animation speeds) because Unity won't let me make the obvious left turn (using one animation with different time scaling) isn't particularly helpful. What would be helpful is a system designed by professional game developers who have experience solving animation problems in commercial games.

 

I never said that you can use IK to change the gate, I said that if you blend two motion that are synchronized, the IK feet stabilizer will make sure that feet stay grounded even if the blend introduced some noise.

I don't understand what you are talking about.
The first thread is about legacy component and feet sliding, this has nothing to do with mecanim
and the two other thread are about setting animation clip speed at runtime which is available in mecanim.

Time scaling had nothing to do with root motion, it the playback speed of the clip, take a look at this image, the same clip is used for walking forward and walking backward, but the time scaling is different and it does work even if root motion is disabled.

So what is your question exactly? it fell more like a rant than anything else

 

I have filed 3 separate bugs on Unity problems that I have run into. Thank you for being helpful on this.

 

@Mecanim-Dev
Is there any way to test the additional muscle settings without leaving the setup window? Things like feet spacing.
It's a pain to configure right now, cause you must: open humanoid setup-> try one value-> save->play scene with animation->if not ok repeat all.

 

No there is no way to test it easily.

It on our todo list to add a Preview window in the avatar configuration tools to allow you to validate those settings by selecting an animation clip from your projects.

 

@DDNA : We do have a fix for your crash in 5.4 for your bug #820110. The crash was triggered by an interrupted transition in the same frame than you were changing the override controller. The fix should be available in an upcomming 5.4 patch release.

 

Thank you very much!

 

Question: Isn't the "Playables API" the low-level animation API you are looking for? http://docs.unity3d.com/Manual/Playables.html

It's still experimental, but it's usable right now. Keep in mind that documentation might be a little outdated because the whole api was converted to structs instead of classes recently, to prevent GC allocs I suppose.

But it's pretty much something that allows you to code your own animation systems very easily. Can't wait until it becomes 'official'

 

>Can't wait until it becomes 'official'

Yea that is the key problem. When you are trying to ship a product on a deadline, that has to work without bugs in the real world, it is essentially a no go.

This is the same problem with the message "This will be in there until we feel it doesn't need to be there anymore."

The question is Unity supposed to be a toy for hobbyists or a real reliable production tool. I assumed it was was second.

If I can't ship stable products in a timely manor I will go out of business simple as that.

 

The scaling thing is weird, I have seen it before as well and so I always have certain guidelines for client animations to help them avoid bugs.

I sold many of these problems by creating an animation button that generates a lot of this stuff automatically. I can click on this button, and it will generate a new animator, State Controller, animation clip, State, and hooks it all up to the game object. The script then saves the new data into the project directory. I would highly recommend doing something similar for your particular use case. Having this little helper system has saved me a lot of time and headache with Mecanim.

 

The scaling issue is a Unity bug that they are fixing.

 

@DDNA The bug has been fixed in 5.3, 5.4, 5.5, you should see the fix in an upcoming patch release for 5.3 and 5.4

The scaling bug was triggered by an interrupted transition followed immediately by a overridecontroller swap.

 

Is this in 5.3.6p3?

 

no not yet, i'm in the process to merge my change into 5.3 main branch, I will let you know when my fix will land into 5.3.

 

How about 5.4.0p3?

 

it was released this week to.

Just finished to merge fixes in both
5.4.0 Patch 4
5.3.6 Patch 4
both patch release are expected to be released next week

 

So today I am running into this. I am just cross-fading between 2 animations on an Additive layer. (v 5.4.0p3) There is no override controller on this animator. If I just play instead of crossfade the problem doesn't come up.

At this point I don't know if this is related to the 3-4 other bugs I have filed this month, because none of the fixes have made it back to me yet.

What should I do about this?

 

Fixes has been verified by our QA this morning in 5.4.0 p4 and 5.3.6 p4, and both should be released this week.

It look like the first bug you did submit so let wait for the fixes to reach you and then if it still occur we will find why.

 

I got 5.4.0.p4 today. It looks like cross fading 2 additive animations still causes problems.

 

so look like another issue, can you log a bug with your project?

Also did you manage to validate if the crash is gone?

 

>Also did you manage to validate if the crash is gone?

I know this would be an ideal situation. My project has changed a lot since then, I pulled the override controllers out because I didn't know when or if they were going to work. I came up with a different strategy for managing this content, I may go back at some point, but right now I would have to validate this on the build I gave you in early August, which is the one I provided you.

I will try to build a test case for this bug as well, otherwise I am going to have to give you this whole project again.

 

I was able to replicate this in a small project, I just reported it. (Case 828199)

 

great looking at this

 

I was able to repro the bug, so we gonna find a fix for it

Thanks

 

Has this been fixed yet? :|

It happens to me on both 5.4.0f3 and 5.5.0b1.

 

there are still some issue with override controller but we did fix some of them for 5.3, 5.4 and 5.5(fix for 5.5 are not yet in the release branch but are on their way for)

Deleting an overridecontroller that was previously used no longer reset the state machine.
Modyfing an overridecontroller that was previously used no longer reset the state machine.

Changing an overridecontroller that is currently used still reset the statemachine, we are working on a fix for 5.5

Code (CSharp):

1.  
2. AnimatorOverrideController overrideController = animator.runtimeAnimatorController;
3. AnimatorOverrideController newOverrideController = new AnimatorOverrideController();
4. ...
5. animator.runtimeAnimatorController = newOverrideController;
6. ...
7. overrideController["myclip"] = myOverrideClip;      // no longer reset the state machine
8. Object.DestroyImmediate(overrideController, true);  // no longer reset the state machine
9. newOverrideController['myclip"] = myOverrideClip; // still reset the statemachine, working on a fix for 5.5
10.