Search Unity

Hi! A couple of months ago, I wrote a post about the new features we’ve added in Mecanim for Unity 5.0.  Today I want to show you some of the cool – and simple — stuff that you can do with our new features.

Random Nodes

Creating random “selector” nodes using StateMachineBehaviours in conjunction with the StateMachine entry node is really easy.

The first thing you want to do is to add transitions from the Entry node to your states.


You will then need to assign each of those transitions an int condition.


Then you add a StateMachineBehaviour on your Idle StateMachine and implement OnStateMachineEnter like this:


So now, every time you will enter the Idle StateMachine, a random State will be played.

Procedural States

In 5.0 we also did some improvements to our Humanoid IK solver and added what we call IKHints. This means that you will now have control on your IK chain roll! Using the StateMachineBehaviour’s OnStateIK callback you can have IK setups that are specific to your states. You can even go crazy and have fully procedural states. The following code will make your character dance!




Sweet dancing! Character by Mixamo

Create your own tools

Since we are exposing the API, you will be able to create all sorts of tools to create and edit Mecanim assets. When playing with 2D, I find it useful to use Blendtrees to do my navigation state. Since it uses sprite animation, I often need to redo the same steps over and over again for my different characters. Using the API, I created a simple EditorWindow: NavigationBuilder So I just need to drag in my sprite animations and the target object. Then I click create to get this: 2DBlendTree The code for the creation of the controller is as simple as it gets:


StateMachines everywhere

A nice thing with StateMachineBehaviours is that you can use StateMachines without animations. So anything in your game that requires some kind of StateMachine-esque logic can use our nice visual editor live feedback.

For example, a music StateMachine :


A menu StateMachine


Soon it will be your turn!

I am hoping that these new features are getting you excited. We can’t wait to see what you guys will come up with!

41 replies on “Having fun with the new Mecanim features”

I like the example of the random idles (or even attacks), but I’ve found that in a large system, this particular solution does not scale.

For instance, add in network updates from other players, add in 5 random idles, 5 different attacks each with 5 random animations (swing low, swing high, etc) and all the sudden, you can’t really rely on swapping parameters around in Mecanim and having it switch states appropriately.

Instead, you need to directly call Animator::Play or CrossBlend. The problem is that you cannot pass a state machine to those methods. As far as I know, there is no way to access sub state machines _at all_ from the scripting API, meaning that while they are a nice visual feature when mapping out state transitions, they are of very limited use when you need to do anything remotely non-trivial.

Minor correction: Since the idle animations are not a blend tree but individual animations, and since your IdleIndex is an int, I think your code should be changed from:

animator.SetFloat(“IdleIndex”, Random.Range(0.0f, 4.0f));


animator.SetFloat(“IdleIndex”, Random.Range(0.0f, 4.0f));

Oops. :-) That would not do at all! :-)

Sorry, copy and paste laziness….

I meant, perhaps, change to:
animator.SetInt(“IdleIndex”, Random.Range(0, 5)); // Assumes range is 0 to 4.

Calling the presented solution for random nodes «easy» is quite a twisted definition of «easy».

If you ever make a tutorial out of this post, what about moving the random node selection down right after the «editor tool» section and change the editor tool example into «creating a random node selection state». This way it may become actually easy to create and maintain random node selection states.

Cool but there’s something I can’t figure it out. I made the same random node example for my idle animations, then I added a transition from the idle sub-state machine to itself in order to loop every time random idles. But I need to exit from the idle sub-state machine too, so I added a transition from it to other states or sub-state machines but even if parameters were changed the transitions didn’t fire. Then I realized that I needed to create an exit transition with its conditions for each idle animation even if I already set the conditions of these transitions for the sub-state machine. Is it right? Because if it’s so it’s redundant. Untill now I used a blend tree for 6 idle animations but the result it’s not so satisfying unless you animate equally all the idle animations for a while till the blend parameter is completly changed, but it’s an hack.

Is there anything else I can do without redundancy to have a sub-state machine that has various enter transitions for different loopable animations and has different exit transitions indipendetly from what animation is playing?

At the moment you have to have invidividual transition from your nodes to the ExitNode ( you can use ExitTime no ?)

What we want to enventually is to have AnyState transitions that are local to the SubStateMachine. I believe this will fix the redundancy.

Do I understand correctly ?

Yea a sort of, something that give the opportunity to link a transition to something like AnyState in order to work with the transitions set between the sub-state machine to which they belong to and other states or sub-state machines


Just a quick question, does anybody know if we’ll be able to set the values of conditions when we leave a state instead of checking for the current state in code? (i.e. set ‘walk’ condition to false when going to idle state.)


It would be fantastic if there was a way to set this visually in the state machine graph. It’s a super common use case for me where I want to basically do a ‘one shot’ event to trigger an animation transition, and just want the variable to reset immediately. Writing code for this each time is a bit of a pain!

Awesome! This looks like some really nice fun that can now be had with Mecanim in addition to what we’ve already had. Especially StateMachineBehaviours sound like a really nice way to open up new possibilities!

One thing I’ve been wondering: As the StateMachines «live» in the project — is there a good way to connect StateMachineBehaviours to scene objects? Like, let’s say I want to call methods on components that are attached to some objects from a given scene — would that be possible? Or would I have to send messages to the object that the animator is attached to so that those could call those methods (those could obviously be connected to scene objects)?

The StateMachineBehaviour callbacks are all passed the Animator component that is executing the machine, so you can call GetComponent on it to retrieve whatever else you need to interact with.

Not at the moment. There is some work required in our UI backend to have zoom supported correctly. But here again, we are working on this.

[…] In 5.0 we did publish everything, take a look a this blog […]

In my experience using mecanim with the new UI to drive UI transitions I’ve found that what it seems like I really need is animation clips to be the transitions between states rather than transitions being a cross fade of two animations. Often I’ll need something to enter and exit view by doing something more complex than simply changing a bunch of variables from one value to another. To have this happen I have enter and exit states each with the animation clips that either bring the UI objects in screen or take them away and the transition between them is 0 time in length. It seems like it would make more sense if the states were the on and off screen states and the transitions between them were animation clips.

Sure, you can set it up to do that if you want — you don’t have to stick to the ‘jump directly from Any State to individual animations’ structure that’s generated for you. You can set up any number of states; just use the trigger parameters as appropriate to play back your transition animations.

Sorry if I’m wrong but I think you didn’t understand the issue of Frank Tinsley, which is also mine.

We just want a way to customize how the transitions work, like, creating TransitionsClips and these clips animate the properties that change from a state to another, or, just customizing the transition at property-level depth in the transition inspector. The actual workaround is to create a intermediate state with an AnimationClip with the transition animation and make the transition between the states in 0 seconds.

Long story short: Instead of doing HidingState —-(0 seconds transition)—-> FadingInState —-(0 seconds transition)—-> ShowingState, we want to do HidingState —-(customizable transition at property-level)—-> ShowingState.

I want to be able to customize the duration in seconds of the transition and to customize the curve (so it’ll not be always linear) of each property that has different values between the states. I agree that can be a little hard to understand but I’ll make a video «simulating» the feature, post it in the internet (probably in Unity’s forum) and link it here. Ok?

StateMachines everywhere! This is really really awesome.

Looking forward for the full release, and trying out these new features.

// chall3ng3r //

The bledtree example is interesting for 2D, still I see it uses mainly editor utilities, would be possible to create the same thing at runtime?

Ok, is also still planned a way to be able to create animations for sprites at runtime? I think I saw that UT was looking into that (not for the immediate future) but I’m not sure.

Since we can now create state machines without animation, it seems strange to run it from an animator component (problem of semantics mostly).

Also, will we have the ability to have more than one state machine running for a given object? As of now, you can only attach one animator component. Of course you can get around this with a child object, but again, if you’re opening things up for uses other than animation, we probably need a more flexible component.

Thanks for the great new tools!

We are working on being able to apply StateMachine to other components. Still pretty much WIP but you will see some cool stuff from us soon!

To have multiple StateMachines, simply create layers!

Great! On the multiple state machines, layers work well, but when the responsibility of the machine is drastically different from the animation (music for instance), it feels strange.

Something else I noticed today was that having the default transition times not set to 0 is pretty frustrating for non-animation state machines. I get this is not the primary use, but it seems like this is a tool that should be global, not necessarily attached to animation solely.

Thanks a ton!

Simply add a StateMachineBehaviour directly on the StateMachine an implement OnStateMachineEnter, like in the selector node example.

I’d love to have a StateMachineBehaviour override that fires once every loop. I can’t seem to figure out how to accomplish that using the current methods in a way that isn’t a terrible hack.

Comments are closed.