Mechanim vs Legacy Animations

Will this allow us to add in a duration type parameter to manually control the fadeOut/In and is there gnna be a possibility to reference mecanim states via dragging onto a monobehaviour field?

 

This is good news.

 

But there are always ways to circumvent this. For example I ask you nicely that if TheSin' assumptions are correct, then DO NOT reply to this comment of mine. So you can actually passing on information while remaining totally silent, thus not breaking NDA.

 

I use the legacy system mainly because I started my current project before Mecanim was implemented and it would be a big hassle to rip out all the old legacy animation code and replace it with the newer Mecanim code when everything currently works perfectly fine.
Future projects will be all Mecanim though, and by then hopefully the Mecanim limitations will be ironed out..

 

This thread will cause an unexpected delay of 4.3. Some Mecanim functions will be added at the last minute.

 

The biggest headache that Mecanim gave me is MatchTarget...

I made it work with one layer with no problem whatsoever.
But.... I'm not sure if I'm doing something wrong....... but with several layers full of blend layers, I can't make it work... sometimes it gets re-positioned... but most time, character wont get re-positioned at all OR weird stuff happens... but ultimately not getting in the position I want.

Is there something wrong with MatchTarget, or I am I messing up with my codez? The later being a very likely situation

Right now I'm manually positioning him by manipulating transform.position... it's the only way I could place the character correctly before he can climb a ledge.

 

lol!

 

"Legacy" is not legacy at all here, for me and its what I use but will look into mecanim sometime in the future.

Without IK tools (free version) though its not something I'm much excited about tho.

 

How about the ability to keep feet planted on the ground when your character is doing a squat animation. That would be super cool!

fek fek fek.

 

How about weights control and layer setup via code ala legacy? 1 means cough its in ;-)

 

@UT,
Give me Legacy and "retargeting" and i swear that i will claim nothing more about Animation.

 

This ^

The legacy system, in the right coders hands is a powerful tool. We can access the bones, weights, speed and play mode etc and create our own editors/tools and do pretty great things. Retargetting is the killer feature!

 

Kavorka is working on a new IK system that should be operational with Legacy.

 

Mecanim transition preview functionality (in the editor) has been broken since 4.2, and I've not seen any other complaints about it on the forums. This hints to me that not many people are using Mecanim...

Retargetting is great, the state machine is mostly great. But the complete lack of code control over it makes it a real pain to work with. You can't manually set an anim position, or programmatically tweak a transition - so simple things (like de-syncing the walk anims of several enemies) are almost impossible.

The lack of a 'go to state, right now!' function and a reset function (for object pooling) are also annoying. And boolean parameters are a really ugly way of triggering a one-shot animation (as you have to clear them, but can't do until at least the next frame)

On mobile, Mecanim seems very expensive (Animator.Update, not the software skinning), but I've not done a direct comparison with the legacy system yet.

Mecanim shows a lot of promise, and could become really awesome, but it still not replace the legacy system entirely - unless it includes an in-Unity animation editor, like the legacy systems, for the times that you just want to animate a one-off object (e.g. a door opening) without getting an artist/animator to create the anim in Max/Maya.

 

Or maybe it is only broken for you, since transition preview works great for me. What issues are you seeing?

 

Can anyone confirm if this solution will work:
a) Re-targeting all animations and an model with Mecanim
b) Export the model and animations with this tool ( Collada file).
c) Use an external tool and convert Collada file to an FBX file.
d) Importing the FBX in Unity for Legacy

 

Sorry if I'm asking this in the wrong thread, but is anyone else experiencing an issue with updated animation editor in 4.3 not displaying any curves at all? To be honest I have always used legacy animation editor as I'm mostly working with animated machinery where simple keyframe sequences are sufficient and no characters are ever present. There, curves appeared in the view right after clicking anywhere on the timeline. Now, in the updated interface, nothing happens.

How can I make them visible again?

 

Did you press the "curves" selector at the bottom?

 

Sounds like headache to me lol! but cool if it works...

 

Does anyone know if in Unity 4.3 can we now access Animations in Mechanim from an Array of Animations Listed on the Inspector the way we can access and play them with Legacy??

If not why not?? I don't understand why this simple feature was not included in Mechanim to begin with... if Unity plans to phase out Legacy as I just read here on the bottom: http://docs.unity3d.com/Documentation/Manual/MecanimAnimationSystem.html why wouldn't they include such a basic easy to use feature like this from Legacy into Mechanim?

I really don't care about the fancy editing tools Mechaniam come with right now... all I want is the same simple, easy to use functionality I get with Legacy in Mechanim, then I have no issue switching over.

Anyone know if what i mention above is possible yet, and or if it ever will be??

 

They bought Mecanim in 2011 (Now Unity Technologies Canadian Office). They spent money for this "techno-casual-designer-bling-bling-tool". And you, me and others hope they will give us a solid and valid reason to stay on the old system?!. Dream on.
UT is a company that makes money. Nothing else. It reminds me this other thread : No More "Cool" Features Please Until Crippling Stuff Is Addressed.
After several pages of doubts and questioning about their new technology, no one from UT has come to write here. Almost sure that this topic will be closed sooner or later.

I bought the tool. This solution does not work.

 

Besides character animations does Mecanim support regular GameObject and camera animations too? I tween stuff mostly but haven't really explored what the animation system can do within the editor. If you know any good tuts please advise. Thanks.

 

Kuroato, this should work as mecanim->legacy
BVH Exporter
https://www.assetstore.unity3d.com/#/content/9634

 

At this rate we'll be able to easily animate 100% in Unity, without any external tools to help.

Unity could easily have a tool for adding bones and skinning, I think...

Couple of months ago I managed to Clone the sharedmesh and add a new bone that affects vertices inside a range radius... but I had a hard time managing the bone weights (while allowing original bones still affect the mesh) I get this unwanted noisy effect when moving the new bone, I can't make weights smooth :-/

 

I hadn't given mecanim a second look given I thought it was all about 3d models and humanoid characters etc.. but now I see it can be used for state systems for 2D as well.. sooo, taking another look

 

I definitely would like to see more tutorials on this new animation system. Especially if we can animate anything. Like GUI controls. And 2D, 3D game objects. This rocks !

 

Thanks superpig, but I mean wow! 4 steps to access Animations? Legacy is simply, Add Animation Component, Change Animation List Size/Value, and Poof! I see all Animations!

Why 4 Steps to Accomplish something so simple... just doesn't make sense. I mean sure your steps make sense if that's how the Mechanim Works, but sooo much dependency on this or that to get one simple thing done is mind blowing to me.

I don't need all this fantasy Mechanim stuff, it's cool for the big guys or bigger complex projects that need them, but what about basic usage for smaller projects? I guess our little projects, and basic usage don't matter in the future of Unity Updates.

 

'Play' is not a member of 'UnityEngine.Animator'
in 4.2.2

does this work in 4.3?

 

I really had high hopes for Animator.GoToState, apparently renamed to Animator.CrossFade now, but they did it the "Mecanim way" again. The reason why im disappointed is that you cant crossfade while you are crossfading, meaning the fade always has to finish before you can crossfade to another state. Otherwise the new call is simply forgotten by Mecanim. In legacy we are able to crossfade at any point of time to any state we need, making it perfectly fast, smooth and responsive. If you cant do that, it will feel robotic, mechanical, unresponsive and sometimes just wrong. It seems like a small thing, but I was trying to do something very simple and it turned out to be the brick wall that cost me a lot of time and made me drop Mecanim AGAIN.

 

Seriously? Unity please dont put in hacks for the legacy system into mecanim if theyre half assed!

So glad i havent wasted anytime on the new update of mecanim.

 

Bleh, throw my hat into the Mecanim-dislike crowd.

Some of these features, like creating curves ONLY for the properties you want, are great; but their implementation kind of throws a wrench into the workflow if you just want to animate gameobjects and not characters. It's become a headache to use Legacy, and legacy animation is all I really want.

Why they would ADD steps to the pipeline for simple animation boggles the mind.

 

if legacy is better with perfomance i say use that. i do. i dont really have problems with states its not that complicated. i just a have a set of variables that i check for in my animations just like mechanim does. i dont have access to ik yet but when i do i will add that code myself - should be a fun project. also its worth mentioning im using a completely hand written first person controller with 100 percent physics and it works i use physics materials and script to control things like sliding. locomotion is also pretty easy to write once you can wrap your head around some basic delta velocity functions and multithreading. as for different characters I have different animations for them because they move differently and i don't want my ai complicated for performance sake ( i like having a lot of enemies in my game ). i think learning how to write your own animation code is relevant for game design. i dont think you will always have a proprietary mechanim system to work with if you choose this field but you will always have access to good old fashioned code. when you learn to reason about stuff like animation states it makes you a better programmer and game developer in the long run - it gets easier and easier.

 

So the argument for seems to be that Mechanim at least tolerable and not as much of a pain as many users seem to think it is. A resounding vote of confidence. I still can't picture the conversation where UT folk said "Yeah, this is a really good animation system, we should totally buy it and integrate it.

I mean when "I don't have any real problem with states..." is about as positive as the feedback gets you have to wonder.

 

I for one love it. I use it for pretty much everything that moves. The more complex use needed, the more powerful it becomes. Especially with character stuff (2d and 3d). You can't really compare the two. I do wish I could zoom in and out in animator, but that is a minor complaint.

Also, the legacy stuff appears to be on its way out. There were some changes that makes it unusable in some cases that came with 4.3. The suggested solution is "use animator".

 

i was so exited for mecanim but after i tried it i wish i haven't
ones you get deep and pass the simple play animation you WILL find the broken and buggy features.
and we are close to unity5.....

 

I find it's most difficult to get information back from an Animator and make decisions based on what animations are being played. For example, if I want an AI to monitor a player for an attack animation and block if appropriate, the AI must poll the player's CurrentAnimatorStateInfo, NextAnimatorStateInfo, CurrentAnimatorClipState, and NextAnimatorClipState (the clips states are arrays which must then be iterated). I can't get the name of the currently playing state, so I have to compare its nameHash to all the possible names the state could be. The AI then decides if there is time to block by dividing the clip's length by the state's normalized time, then dividing that by the animator's speed. It's too convoluted.

I tried making my own state machine using the CrossFade call so that I could keep track of what was going on myself, but CrossFades are always atomic; there's no way around it. So that was out. Then I figured I could use animation events to signal to my script when an animation was finished. However, these events were triggering even if the animation was already in a transition out, etc.

None of these are bugs per se, and I've created quite an apparatus to work around them, but they illuminate how obtuse Mecanim can be if you're trying to exert any control over it beyond reading and writing variables from its blackboard.

 

I think the overall design of mecanim is pretty good. But it definitely has a lot of niggles, more so than most of the other systems.

 

What about this : Mecanim Control...?

 

That does look pretty cool. A pity it uses undocumented methods and doesn't support layers. I'll be subscribing to the thread, though, no doubt.

 

i think its easy to fall into a trap relying on proprietary systems to do your animations for you. sometimes the harder things in life are more worthwhile. we all want an easy fix for this kind of stuff i agree but easy does not equal better. if you follow this paradigm fully you will end up with toolkits that help you use toolkits that help you use toolkits instead of just coding it.


i as well as many others would be really upset if unity was to scrap the legacy animation system. i still use legacy particles and legacy animations because they are more performance friendly and tie in with unities paradigm of doing things instead of some new proprietary third party way, also they werent broken before so why fix them. there is no "easy" fix for a lot of these things, game design is tricky if you think some system is just gonna solve everything for you i would say this is a fallacy. if unity keeps changing systems like this if i were using mechanim i would be nervous that unity might change their animation system yet again, in other words if they didnt get it right the first time (supposedly, that is to say if you dont believe code is good enough to make animations) then what makes you think reinventing the wheel with mechanim is gonna be the right move. at the end of the day all of this stuff with the exception of animation retargetting can easily be done in a few days or weeks with some basic code involving raycasting and math, the same way programmers have been solving problems for years. we can have unity code that stuff for you with mechanim or you can do it yourself - im telling you getting this kind of practice and hands on experience with animations is very valuable in the game design field - unless of course you are not in this for the long run and are just doing this as a fun little project then thats another story.

what i love about unity, and why unity will always be the engine for me, is that it allows for both. if they took that away of course i would be forced to use mecanim and then i would have to throw away about 10,000 lines of animation code i've been working on for close to 2 years now. graphical toolkits should always be an extension of programming, not a replacement, lets hope it stays that way.

i know this post probably flies in the face of a lot of widely accepted opinions in the unity community. however i feel that by voicing my opinion in here my feedback and others' will help unity to continue to be the best engine that it can be for myself and other game developers across the world.

 

It sounds you are trying to do things the old way, in the new system without leveraging the features that make it what it is.

I say this because it is exactly what I was doing a few months ago. I didn't really choose to learn mechanim, I was kind of forced to. There was some critical features/fixes in 4.3 that made it worth while for us to upgrade our current project. Unfortunately, the upgrade broke the ability for me to continue to use legacy anims. (and broke existing animations). So I had to switch. At first I was just doing what I was doing before, but in mechanim. Which as others have pointed out is extra steps, and awkward. But once I really spent some time with it wrapped my head around it, and started leveraging the features of it, it made everything much faster and cleaner. (despite the bugs).

In your example, you could leverage the state machine to simplify the flow. For example, your AI doesn't really need to know anything about animations at all, they are just visuals. The animation states are really only important to the animation, not the rest of the game. In your example your AI only needs to know that player is attacking, correct? You could:

Simplest:
Add an "Attacking” bool, and set it to true in when the attack anim plays. Then your AI would only have to poll the animator for the “Attacking” bool. — thePlayerAnimator.GetBool(“Attacking”)

A little more robust:
Skip the polling overhead, and just add a delegate listener and fire the event from the attack anim. Subscribe to the player controllers event, and you AI be notified when the attack is played. This abstracts even more cleanly as the AI now doesn’t have to ask the animator constantly if it is attacking, the player notifies it when it attacks.

Ramp it up further:
Forget calculating time. It is not only extra work but it means you may have to adjust code if you change the animation. Again, just boil it down to the minimum amount of information your AI or game controller needs to know to take action. In the blocking case, the AI only needs to know if it is too late, or of the block didn’t complete before the attack did. You can add events to the the exact place on the time line something is happening. Say it is an sword vs shield. fire an event to saying when the attack starts, fire another when the sword is fully extended (when it would hit). On the enemy to the same but for the shield is fully up and have a bool like “Blocking” that is set when the shield is up. Then when you attack, when the attack hit is fired off, you only need to check if the enemy “Blocking” is true at that point in time. If it is, he got shield up in time, if not, he was too slow.

Or to go even fancier, make blocking a float from 0.0 to 1.0. In the timeline set to 0 when the blocking starts, and 1 when the shield is up. Then when the hit occurs you can multiply the damage done by how far the shield was up. So the player does more damage the faster he attacks.

-----

Anyway, those are just rough examples. But all of them are really only a line or two code and some minor tweaks in the animator. But very easy to maintain, and really quick to change and expand.

For a 2d battle game demo I built, I built all kinds of attacks, and different hits on that responded to the attacks. I even went as far as to use layers in the animators to make the character appear more damaged weighted by their current hp. The actual fighting code was very, very simple. Player attacks -> animations play -> animator returns results. I didn’t actually have to “code” any animation controls at all, the state machine takes care of it all.

Once you really get into how it works, it is easy to find really effective and powerful ways to leverage it. I had no interest in using, but after I started using to its potential, things are more complex with out it for me.

 

I too would hope they don't scrap it either. I can't imagine that they would need to. There are many places where the simple anim system is perfect and mechanim would be overkill.

 

agreed

 

+1