Are you still using legacy animation system?

I am still using the legacy animation, unless it's an humanoid character. For me (a programmer), it's easier to manage animations in the old system. I can freely add/remove animations, set its timing/layers etc. It doesn't need another file to get a GameObject animated.

The Mecanim is good for artists and programmers working independently. And it's easier to create smooth and complex transition. But for a small develop team, I don't think we always have enough content to enjoy its benefit rather than pain.

 

Like you said it depends on what I am doing and or working with.

Then there is times I use neither and get what I need through scripting.

 

We use it in KSP also. Mechanim wasn't released when we were developing the EVA system, so the whole thing was implemented with legacy animations. I still find it easier to work with from the coding side, although admittedly I haven't had many opportunities to work with Mechanim a lot. I'm just glad both systems are in.

Cheers

 

Yeah, there's plenty of stuff that the legacy system is better for when it comes to workflow. Also, last time I worked with Mecanim trying to do certain things there were limitations that the legacy system didn't have. (I'd of course have to re-write a lot of stuff Mecanim does out of the box, but at least that's an option with legacy, where you can't add lower-level functionality to Mecanim.)

 

Nope. Legacy is deprecated and has limitations/bugs that aren't going to be fixed. Personally, I never use it, and we have nearly stripped it all out of our game.

 

95% mecanim now. I resisted for the longest time, but I'm glad I worked through it, it doesn't take long to rewrite legacy to mecanim code once you've set up your anim controller. The animation timeline event system is handy as hell at times.

 

Totally!
I do wish the setup for an anim was a little more streamlined, but I eventually just wrote an editor script to create all the parts at once. Given the way it is used in the new GUI, it looks like it will be getting some improvements to that part down the road.

 

The first one that jumps to mind is changing the speed of animations without changing the speed of the whole system and/or including multiple copies of the animation (which introduces artifacts anyway I think).

Another was controlling dynamic state changes. A timely update was issued which added that functionality, but I couldn't find a way to get data about the current transition (eg:identify the source/destination state) without giant and unsupported reflection hacks, which means my code couldn't reliably do certain things.

That was a fair while ago, though. About a year. I got everything I needed going with one system or the other, and haven't had to add/change/update since. Hopefully one or both of those have been fixed in the mean time.

 

Yes, at runtime.

I think the lack of information was the issue. All we can check there is the name and the hash of the transition, which is of quite limited utility. For instance, I think that one use case was trying to start a dynamic transition to a state only if not already in a transition leading to that state. For this we need to be able to see what the target state is, but I'm unaware of a way to do that. I think that the best solution suggested for that was to enter all possible transitions manually, and run some funky editor code to save out a separate data structure where we could look up which ones went where.

 

Sweet. Did I miss GetNextAnimatorStateInfo a year ago, or is it a more recent addition?

It's also possible that wasn't quite the thing I couldn't solve. But I think it was that.

 

Ok, looking through my old docs it appears that might not have been one of my stumbles. At least, I'm not seeing any mention of it here.

One is in regard to transition speeds varying depending on the source/target animation state, though I did solve that one. There's other stuff here, too, but I'd need to read in more detail to see what I solved and where I got blocked.

 

Currently using a mix of legacy and Mecanim. But we may end up removing Mecanim entirely, so we can do more dynamic loading of animations.

Mecanim still lacks direct script control over far too many things. In particularly, it needs support for modifying animation states from scripts - assigning replacement anim clips at run-time.

Is there even a way to manually set the position of the animation within a state? - or change the speed of a single state? - last time I looked (admittedly a few versions ago), I couldn't find a way, and that seemed like very basic functionality.

I've recently written a 'skinned anim to keyframes' tool - to let us used keyframe-interpolation to animate lots of low-poly humanoids (without the high cost of skinning and a complete skeleton hierarchy, for mobile). This tool was fairly trivial to implement using the legacy system, but as far as I could tell, not possible with Mecanim (forcing an anim into a specific state *in editor mode*, for a SkinnedMeshRenderer.BakeMesh)

And even for the cases where Mecanim works well, I find it quite a struggle to write code that can stay in sync with the animation state (in particular, doing things in code when a state is entered or exited). Having to deal with hashes is very un-Unity-like (please expose the state names as strings, as I suspect many people must run into the problem of hashes not matching due to unclear naming conventions when you've got sub-state-machines)

Then there's the simple stuff - animating a door opening, or an object spinning around - where it's much easier to use the legacy system (and animate it within Unity), rather than dealing with the additional setup work required with Mecanim.

Yes, it's nice to be able to set up nice blends and anim-driven-motion with Mecanim, but right now, it feels like you have to make too many sacrifices, in terms of direct code control, to get that.

 

Yes I am, not because I think it's better or worse, but it's what I've got used to, and I'm half way through a project and I want to stick to one animation method. Next project might use Mecanim... or not, I'm not sure. After all legacy has all I need and all I want from an animation system... which is 1) a list of animation - 2)be able to control their weights / time / normalized time / speed / enable or disable, from a script, that's it. I mean with legacy you have absolute control over animations already, in theory you shouldn't need anything else. Mecanim has some interesting added functionality, stuff that probably can save you valuable scripting time, but I've only scratched the surface, I haven't studied it thoroughly yet, it's in my to-do list.

 

We tend to use the legacy system if there's only a single animation being played. Think a tree moving in the wind or a door being opened and then staying up. Then we only need one asset (the animation), rather than two (animation and controller).

For anything more complicated, or for imported models, it's mechanim all the way.

By the way, the Unity 5 state machine behaviour is so amazing that I back-ported it and use it to run our AI. Being able to use mechanim as a state machine is fantastic - though it would be cool if there was a stand-alone state machine that was independent of animations completely.

 

Yes I still do mainly because I have no idea how Mecanim works, I tried to set it up to use the Optimize GameObject option but all my animations stopped working. There's also the fact that I read somewhere that Legacy had less overhead compared to Mecanim, I'm making a city building game and you can see up to 100 people on the screen at a time.

It looks amazing for third person or first person games but for an overhead distant camera it seems a bit overkill.