Legacy or Mecanim animation for changing equipment and skills

This is for a 3D game.

I have a system which allows me to take in different equipment such as a sword, Bow, 2-handed sword, Dual wielding swords, holding a sword and shield, Staff, etc.

Each weapon is different enough to require its own set of skills to simulate a different fighting style using the weapon. Each skill has its own animation unique to itself to be played, and blends in with the lower body animation if needed.

The player is able to sheath and unsheath weapons, and is able to change their skill loadouts for each weapon in a skills window.

So far this system uses Legacy Animation to run its animations and works great. What I am curious about is how this same thing might be done in Mecanim.

Feel free to ask questions to clarify details

 

Have you tried messing around with using Mecanim at all? It's not too complicated. I'm actually using a similar system as you, with different times of equipment, and such. Now, I'm no expert on Animation, but I just use parameters in my animator controller to decide what type of animation is supposed to be playing.

 

I've used Mecanim before. Infact I transitioned from Mecanim to the Legacy animation system.

Mecanim as I understand it is a state machine, which requires the animation to already be in the animator controller. This did not work well with my need to change the attack animation based on what weapon the player was holding, and what skills the player had in their loadout. Having an animator controller which just has everything stemming from "AnyState" would have been pointless, and a waste I feel. Having several animators for different weapons would also have been a hassle.

The above considerations led me to using the Legacy animation system instead which simply played or blended an animation you told it to play or blend. This also fitted well with having an animationclip in my skills and simply asking to play that animation if the skill was executed.

So to anyone who is more proficient at Mecanim, I ask how the system I described in my original post would be implemented using Mecanim instead.

 

Sorry I don't have an answer for you.

This is the primary reason I don't use Mecanim in my projects, because it's not easily animation agnostic. Heck... if you have 2 player models with the same state machine structure, just slightly different anims... you have to create 2 whole Animator state machines... and any change you must duplicate over both... and this grows as you add more characters!

Maybe there's some way to work around this... but I don't know what it is, and several other issues I had with Mecanim made me just not care to figure it all out.

This is compounded by the fact that my artist/designer finds Mecanim a giant pain to work with. He'd rather me create all the moving bits of code, and just have a place to stick in the animations, and they just work.

Which with legacy I can do. I just create fields to put the animations, and he creates them and fills them in. He knows what's missing, if a field is left blank.

So I stick with legacy as a result... though I've built a small library of stuff around it to extend it a bit further since Unity pretty much has left it in the dust in favor of mecanim:
https://github.com/lordofduct/spacepuppy-unity-framework/tree/master/SpacepuppyAnim/Anim

 

Isn't this what Animator Override Controllers are for? Like they literally find and replace animation X with animation Y....

 

Possibly, but I left Mecanim behind quite some time ago.

This is why I said:

 

Ah I see, interesting. Although as far as I can understand from reading your link, it seems the Animator Override Controller simply "extends" from the original base. Is the Animator Override Controller additive in nature? Lets say Override1 affects animation state "Skill1", and Override2 affects animation state "Skill2". Will Override2 change "Skill2" without affecting changes made by Override1 to "Skill1"?

And in my case, the player is supposed to be able to assign any skill to any skill slot. These changes have to be done at runtime. Definitely not keen on having a huge bunch of animatorControllers, override or not, just to fit every possible permutation of skill combinations for every weapon.

 

Pretty much this. Overide controllers let you use the same state machine with a different set of animations.

Combine it with proper masks and it looks like it will do everything the OP is asking for.

I feel like I read somewhere that the legacy animation system is being pulled soon? Don't quote me on that one.

 

NO! YOU SHALL BE QUOTED!

But yes I did hear news about this which makes me worried. I would like to keep updated on Unity versions, while being able to continue using what I've created here. If Legacy is pulled, this will nolonger work, and i am wondering how this would be done with Mecanim.

If you can answer my question from my latest reply that would be great. Unless Masks was the answer to having an override be additive

 

They better not.

I have a laundry list of things that either can't be done, or are extremely tedious to do in Mecanim.

Until they resolve all of them... or at least give a much better code side API to mecanim... they better not.

As is it's very designer focused, and code ignored.

 

Here is the thread I was talking about.

https://forum.unity3d.com/threads/legacy-particle-system-deprecation.420351/

Astute readers will notice it says nothing at all about the legacy animation system at all. You may resume breathing.

Sorry about that.

 

I use both systems interchangibly, Mecanim more for mapping out what animations are needed, handling most imported humanoid animations, and putting in clean blends of the animations our animators bring in. While I typically use Legacy on animations built from scratch directly in unity, or when the animation needs to be tightly coupled with certain components on a gameobject.

My Animator Controller has 6 layers ("Base"| includes Hips down, "UpperBody" |includes torso neck and head, a layer for each arm and a layer for each hand). In the root state on each layer I have a collection of substates named against the item the player would wield (like a Sword) or ability they could do (like climbing ladders) within each substate it can be broken up further but nearly all of them would have a Movement state (a blend tree of root motions) and any action state animations (equip/unequip, enter/exit, pickup/drop, Use, Aim, block, recoil, etc.). movement state will typically be the idle state

I actually use the Third Person Controller Asset from the asset store which doesn't really link states together with transitions (instead uses crossfades via code). and its made setting up character animations easier. I actually don't use the "Any State" at all. Only transitions I make are those where a specific animation shouldn't be interrupted and must follow through to the last animation

I also use Legacy system to great effect as well. and sometimes I don't use it as an actual Animation system, but as a way to interpolate a significant number of properties on an object with a singe Lerp value, especially for Particle systems (where not all the properties are easily accessible via code). could you imagine setting up dozens of Lerps for properties in the particle system (and only on the properties you could change at runtime)? The Animation Panel and its keyframing trivializes that. And in this sense now I don't see the time slider as a time value, but as the lerpvalue I would feed into Animation.Evaluate. it actually works pretty well for my procedural fires.

This is my stance on Override controllers. I don't like them. Don't get me wrong they work for what they are designed for, but they are far too lacking...

for starters if you have two states using the same clip (but for different circumstances) you have no control of which state get overridden and which won't, either you have all instances of that clip overridden or you have none. Override Controllers only tracks unique animation clips and fully remaps all instance uses of a specific animation clip to another clip.

the another issue is with blending. a certain transition may have been set up with the perfect amount of blending between two clips. and while the controller is mostly the same, with the two animation clips being different you might want slightly different blend settings. Override controllers have no support for that

And finally the last caveat is with StateMachineBehaviours. now if your SMBs lack SerializedFields (as in theres no fields drawn to its inspector) then theres no real issue. but if you do, then what ever you have in the base controller will have to also work for any overrides, cause it can't be different in the overrides.

Unless your Controller is simple, I'd say you're just better off duplicating the Controller as a new asset. It does mean more maintenance, but Override controllers just don't save enough time on hardcore Controllers to be worth.

 

In this case, does this mean every single animation a character would potentially do (in my case would be every single skill animation regardless of whether the relevant weapon for the animation is in the character's possession) is in your animator controller?

Transitions sounds reasonable, sounds like what I'm doing with Blending in the Legacy Animation. Although is this something unique only to the ThirdPersonController Asset?

Yes animations does have many interesting alternative uses, I've used it in a similar fashion as well, but never thought to use it to control particle properties.

 

If the character could possibly do that animation, then it will be in its controller. think of the Animator Panel as a blueprint for all the animations the character can do, and you can use transitions (and exit conditions on each transition) to control when those states are entered|exited. if two wielded items have identical animations and states then you can have both items simply use the same substate.

Transitions are part of Unity's base Animator system. Crossfade is a built-in function in Unity. The normal way to use the Mecanim was you link transitions everywhere (well not everywhere, to exit nodes and usually spoke states). The ThirdPersonController however listens to AnimationEvents for when to determine which state to fade to and then directly fades to that state via code, meaning I can get away with using transitions sparingly .