MecAnim: Code vs Animator Tree Performance

I’m hoping someone can shed some light on this for me because there’s no way my conclusions on this can be correct. Based on my limited experience with MecAnim (as well as my particular game, of course!), it seems silly for me to bother with the Animator tree at all.

I understand that avoiding the tree (aka not creating parameters, not setting parameters to transition from one state to another) forces me to lose any specific blending I may have used during a transition from 1 state to another. As far as I can tell, that’s almost the only downside to not using the tree.

MecAnim, performance wise, gets more expensive as the tree gets more complicated. Having more transitions means more checking to see if/when it should transition. Having transitions from the Any state means they’re checked constantly. Why would I want to bother having extra checks within the Animator system when I’ve already performed those checks in code (when I would typically set the appropriate variable to prompt that transition).

This is getting wordy, but really my question is:

Why set some parameter in code that would lead to the MecAnim system doing more checks and blending, when I can simply call CrossFade( stateHash, duration)? The CrossFade limits my blending which I have yet to come across a case where it actually mattered.

I’m highly inclined to have almost no parameters (except those for my walk/run blend trees) and simply call the transitions myself in code using CrossFade. This avoids the numerous parameters and extra checks that mecAnim would have to do.

Is this way off base? If the CrossFade is enough for my transitions, why on Earth would I bother with parameters and states?!

Thanks!
-Matt

Absolutelly. In that case, view Animator Component and the whole mechanim system as a window for visualization of your states, for perhaps easier debug. Remember that you can have state machines within state machines, which can make things much more complicated trying to keep it all in head.

Not mentioning blend trees (which could blend between child blend trees), where animations might be synchronized between forward_run strafe_left_run and strafe_right_run.

Of course this could be implemented via code. In fact, for my current project does cross fade. However, if you have lots of complex animations / are working with animators / designers who are focusing on arranging animations within tree and don’t want to look at your code, it is easier (it encapsulates your code and visual representation of animations, and what transitions to what).

However, if you are motivated by performance only, don’t worry. Your animation graph has to get VERY complex to make any difference, and most likely the issue will be in something like “too many skinned meshes not being able to be drawn” or something.