Mecanim Performance and Optimization

If you attach elements to the bones of the player character (like weapons) , can this generate framerates issues, if we have lots of elements?

When you have no animations playing on the additional bones, the cost should be negligible. Otherwise, you could expect to have a relative cost for each additional bones ( ie 15 additional bones on a rig that already has 30 bones, should be 50% longer to solve), in Generic mode. - Note that you can have additional bones in Generic and in Humanoid mode

How expensive is another layer in the animator? (synced/not synced)

Most of the time in Mecanim is evaluating animations. We kept the overhead for layer/stateMachine very minimal. So it really depends on what animations/blendTrees are played by the layer.

Does the layer cost when the weight of it is 0?

Unity does not skip all computations, but does skip the most expensive ones

Does the animator use cpu even if a controller is not set to it?

No, From version 4.1 onwards

How can I optmised my Mecanim scene?

There are many optimisations that can be made, some usefull tips include:

Use hashes instead of strings to query the Animator

• Implement a small AI layer to control the Animato. You can make it provide simple callbacks for OnStateChange, OnTransitionBegin etc...
• Use 'State Tags' to easily match your AI StateMachine to the Mecanim StateMachine
• Use additional curves to simulate Events
• Use additional curves to markup your animations (for example in conjunction with MatchTarget : http://docs.unity3d.com/Documentation/Manual/TargetMatching.html)

Simple animation performance

It looks like right now, the Mecanim overhead when playing a single clip with no blending can make Mecanim slower than the old animation system. The old animation system is very direct, sampling the curve and directly writing into the transform. Mecanim has temporary buffers it uses for blending, so right now there is additional copying of data of the sampled curve data etc. For a single animationclip the old system performs pretty well I guess.

The mecanim layout on the other hand is optimized for when you have animation blending & more complex setups.

We'll take a look at optimizing Mecanim for the case of only a single animation playing.

Humanoid vs Generic performance

IK pass enabled and you have Foot IK enabled on your animation states: You will get better performance with Generic mecanim mode.

When you use Generic, using root motion is more expensive than not using root motion. So if your animations don't use root motion, make sure that you have no root bone selected.

On Android you will get worse performance right now since we don't do NEON there at the moment. Especially humanoid mode is very math heavy so can easily be 2-2.5x slower without neon. This explains the performance difference you are seeing ios / android. [randy: Apparently we're re-adding NEON support in a future release, so hopefully this will improve quite a bit on modern Android devices]

Don't use scale curves

Artists simply put scale curves that don't change any of the values. Always double check that this isn't happening. Make sure that there is not a single scale curve on any animationclip.

Best write an assetpostprocesor to remove it or warn about it.

Combine skinned meshes whenever possible

Your character has two skinned mesh renderers with 3 material on each skinned mesh. Splitting a character into two skinned mesh renderers is a bad idea performance wise. Having one with more material is better.

Best is having 1 material but most of the time 2 materials are necessary to make artists happy.

Page last updated: 2013-03-06