Mecanim Review (Unity 4.2)

[Mistermind]

Surprisingly enough I haven’t found many topics like this so I guess I could give everyone a hand here and give my review of Mecanim system and why Legacy is still the favorite for a lot of developers:
PS: 4.3 still do not solve most of these problems, but it did give enough opening for the creation of this tool: Mecanim Control

Mecanim Review

The Good:
Visual editor
Mecanim gives a way to visualize your animator logic just like playMaker does for coding. Very useful to view, debug and blend your animations. Be able to visualize and modify the curves gives a great sense of control to reduce the “stiffness” of animation and blending.

The animation control is handled by the animator
What that means is that you don’t have to build your own classes to control when or how to start, stop or blend an animation. As long as one animation has a transition into another a simple animator.setBool(“crouching”,true/false) will take care of everything.

Built-in mirror option
One of the most important addition in my opinion. There are currently no built-in function like this in the Animation class and the only solution I found is not very elegant.

Blend-Tree
A very powerful tool. Currently the best solution for solving the most problems with the lack of the animation component.

Humanoid Rig
Being able to swap characters and add animations from other rigs is a very useful way to get around animations and model limitations without the use of a second software.

The Bad:
Visual editor
A great tool, no doubt about it. But unfortunately to preserve its structure, the only code access is parameter sending. Meaning the necessary transitions and clip storage must be done in the Animator. One of the characters I work with for example has around 30 usable animations. Some of them can be triggered while walking and idle, others can be triggered while crouching or jumping (meaning jumping-falling-landing). Some attacks can blend into other attacks and sometimes you want to create combos by tweaking animation canceling and frame link. That can all be accomplished by the Mecanim, but it won’t be pretty. You definitely won’t like it when you have to set 10 different transitions into one animation or vice-verse. With Mecanim, animation clips can only be referenced and played within the visual editor and nowhere else. Transitions must exist between all animations, so you can imagine the mess it can turn into.

The animation control is handled by the animator
Mecanim is built around the idea that your animation logic should be handled by the visual editor. Code wise, the only things you set are parameters and a couple global variables. At first it seems good and easier work, but soon I found out that a lot of my debugging had to do with one or two transition arrows missing or a sea of conditions around the Animator inspector. The urge to be able to serialize all this is tremendous.

Built-in mirror option
Because of limited code access, you can’t just manually set variables from clips. Unfortunately, the mirror option is only accessible through the clip state itself inside the visual editor. The only way to work around it is well … improvise

2 sub-state machines one identical to the other, more then 30 animations on each, several cross-transitions and tons of exceptions. One with all the animation’s “mirror” tagged in, the other without. As a programmer, that bothers me tremendously and you can imagine the amount of times I have to simple delete an entire sub-state, create a new one and re-tag the cross-transitions just because I spent too much time tweaking values on one side.

AnimationClip/animation.AddClip is no longer a thing
Meaning if you are creating packages so others can use, there is no escape from the Mecanim structure. In my case, while building Universal Fighting Engine, allowing the user to simply drag an animation clip into a script on the inspector seems a lot less complicated than navigate them through a confusing blending structure and teach how to create transitions to each animation it should blend into.

Conclusion:

• Easy to use interface
• Manual tweaks and preview window allows for very smooth blending
• Humanoid Rig/Mirror/Blend-Tree

• Most basic operations inaccessible through code
• Visual editor dependency
• Too many animations can get messy

I started working with Unity after Mecanim was already implemented, so I’m not defending legacy because of any kind of tropophobia. I came here with both tools available and felt like the only way I could accomplish my goals was to use the outdated legacy, even though Unity states that we should all change to Mecanim:

Prior to the introduction of Mecanim, Unity used its own animation system and for backward compatiblity, this system is still available. The main reason for using legacy animation is to continue working with an old project without the work of updating it for Mecanim. However, it is not recommended that you use the legacy system for new projects.

I hope this helps! I’m still a big fan of the product as a whole and I can easily see the uses of it. I just don’t understand the “deal” with visual editor dependency. It just limits the potential of everything that was built around this amazing tool tremendously forcing big projects to stick to legacy.

Cheers!

[pixelsteam]

After having gone through intensive Mecanim training solo for the last two days…you are right on the money.
Good perspective…

[Mistermind]

Thanks =)
I really wish Unity could enlighten us on the paradox of having so many tools to help control the animations without the need of a third party software (which is great news for programmers) yet leave the basic stuff a programmer would need out of the picture

[Mistermind]

The solution to our problems! (made by yours truly)
http://forum.unity3d.com/threads/224315-Mecanim-Control

[Velo222]

The worst thing I’ve found using mecanim so far is that I cannot non-uniformly scale my characters by simply setting the scale on the transform component (as far as I know). It works just fine with legacy.

[Suiko6272]

So I’m making a 2.5d brawler and I was tempted to give up on mecanim and explore the option of using your control with my team. Namely the issue I’ve been dealing with is trying to utilize Any State with a Facing Left/Right sub-state (I came to the same conclusion you have above) I realized I would have to check the direction as a parameter on EVERY Any State and simply copy/pasting would mean I’d have to edit every Any.

That got me to thinking though and I kinda just wanted an opinion as I’ve read several of your UFE posts and like what your doing. Why don’t we use a boolean based blend tree? Yes they only accept floats but setting the float of “Direction” to only being 0 and 1 it’s essentially a bool. Then you can either have your Left Right animations within the same state node. Things like Punch would need to prevent a Direction change once you start, so in code you’d simply prevent Direction’s value from being passed to the Animator from the controller while in X state and in my mind I think it is very manageable this way.

This has lead to something that doesn’t require me to copy/paste/edit a “left” state. Just every state is now a blend tree which I’m sure has that extra tiny performance hit but is amazingly simple to keep organized and make changes as you only need to edit 1 state’s transactions instead of 2!!! Now if only blend trees were colored differently then normal states like sub states are…

Edit:
Just prototyped it out and the only trouble I’ve had is I missed changing a state into a blend tree. It’s actually a really nice setup and the handling of “mirrored” in code is the same.

[Mistermind]

@Suiko6272

So I’m making a 2.5d brawler and I was tempted to give up on mecanim and explore the option of using your control with my team. Namely the issue I’ve been dealing with is trying to utilize Any State with a Facing Left/Right sub-state (I came to the same conclusion you have above) I realized I would have to check the direction as a parameter on EVERY Any State and simply copy/pasting would mean I’d have to edit every Any.

That got me to thinking though and I kinda just wanted an opinion as I’ve read several of your UFE posts and like what your doing. Why don’t we use a boolean based blend tree? Yes they only accept floats but setting the float of “Direction” to only being 0 and 1 it’s essentially a bool. Then you can either have your Left Right animations within the same state node. Things like Punch would need to prevent a Direction change once you start, so in code you’d simply prevent Direction’s value from being passed to the Animator from the controller while in X state and in my mind I think it is very manageable this way.

This has lead to something that doesn’t require me to copy/paste/edit a “left” state. Just every state is now a blend tree which I’m sure has that extra tiny performance hit but is amazingly simple to keep organized and make changes as you only need to edit 1 state’s transactions instead of 2!!! Now if only blend trees were colored differently then normal states like sub states are…

Edit:
Just prototyped it out and the only trouble I’ve had is I missed changing a state into a blend tree. It’s actually a really nice setup and the handling of “mirrored” in code is the same.

If there is one thing I love is brainstorming while writing a post =D I can’t tell how many times I’ve done that hehe.

In terms blend trees, I decided to ignore that approach entirely mainly because it wasn’t doing what what I had in mind, but there is a lot of potential in terms of blendtrees and a possible fix to the crossfade issue.
See, mecanimControl.CrossFade and mecanimControl.Play are just very enhanced methods to basically use the built-in animator.CrossFade and animator.Play. Problem is, this built-in CrossFade is basically defective.

With blendtrees, one could technically create a float parameter that goes 0-1 and use that parameter to emulate a “blending duration”.

Something like this:
Mecanim Control Required
This has not been tested
1 - Under each AnimatorControler (Resources\controller), replace all states with a blend tree.
From this:

To this:

2 - Use the functionalities under the private function _play inside MecanimControl.cs to replace the clips inside the blending tree. Since OverrideAnimatorController works by basically replacing the clips inside the state machine without actually accessing it, it doesn’t matter if the clip is under sub states or blend trees.

3 - Create a new parameter that can be used to control the blend tree.

3 - Now things get a bit complicated: Inside the _play method, replace the animator.CrossFade with an algorithm that sets the animator parameter to go from 0-1 by a speed factor serving as an emulated Blending Duration;The lower the speed, the higher the blending duration. This algorithm needs to be on FixedUpdate and triggered by _play.

If anyone wants to try this approach let me know the results. As soon as I get some spare time I’ll try that myself.

[Suiko6272]

It’s exactly what I have and it sounds like it’ll work perfectly in your control, honestly if we get in a situation where we need to pragmatically add clips I’m sure we’ll just spend the $ on your product instead of having me spend time making the exact same thing xD Learned alot about mecanim in general since finding your posts so thanks for all the trail blazing ^^