Search Unity

  1. Looking for a job or to hire someone for a project? Check out the re-opened job forums.
    Dismiss Notice
  2. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Are you still using legacy animation system?

Discussion in 'General Discussion' started by SunnyChow, Jan 6, 2015.

?

Are you still using legacy animation system?

  1. Yes

    34 vote(s)
    82.9%
  2. No

    7 vote(s)
    17.1%
  1. SunnyChow

    SunnyChow

    Joined:
    Jun 6, 2013
    Posts:
    352
    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.
     
    protopop likes this.
  2. Nubz

    Nubz

    Joined:
    Sep 22, 2012
    Posts:
    553
    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.
     
  3. HarvesteR

    HarvesteR

    Joined:
    May 22, 2009
    Posts:
    500
    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
     
  4. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    13,459
    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.)
     
  5. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    8,291
    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.
     
  6. lmbarns

    lmbarns

    Joined:
    Jul 14, 2011
    Posts:
    1,483
    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.
     
  7. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    8,291
    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.
     
  8. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,428
    Do you remember what those things were? Asking for a friend.

    (I think the team are well aware that there's workflow improvements that can be made, but if there's actual missing-feature points of inflexibility then that's potentially more interesting).
     
  9. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    13,459
    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.
     
  10. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,428
    At runtime, you mean? (Changing the speed at edit time on a per-state basis is already doable).

    Right. We have GetAnimatorTransitionInfo, but it doesn't give you a huge amount of information. Any chance you could describe an example use-case for this that I can evaluate?
     
  11. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    13,459
    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.
     
  12. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,428
    Animator.IsInTransition() and Animator.GetNextAnimatorStateInfo().
     
    IcyPeak and angrypenguin like this.
  13. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    13,459
    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.
     
    IcyPeak likes this.
  14. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,428
    I think you missed it. Reckon it was in 4.0.
     
  15. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    13,459
    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.
     
  16. bluescrn

    bluescrn

    Joined:
    Feb 25, 2013
    Posts:
    545
    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.
     
    Last edited: Jan 8, 2015
  17. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,428
    Have you looked into Animator Override Controllers? (They're not in the manual so I wouldn't blame you for having overlooked them).

    Animator.Play, with a normalizedTime parameter provided.

    At runtime, no. At edit time, it's in the Inspector for the state. You can sometimes work around this by setting up a blend tree in the state to go between 'minimum speed'- and 'maximum speed'-configured versions of the same animation.

    Ah, you mean like GameObject.SampleAnimation() under the legacy system? Good point, I'll investigate whether something like that exists in the new Editor API for Mecanim in 5.0.

    Hopefully, the new State Machine Behaviours in 5.0 will take all the pain out of that. :)
     
    bluescrn likes this.
  18. dogzerx2

    dogzerx2

    Joined:
    Dec 27, 2009
    Posts:
    3,884
    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.
     
    Last edited: Jan 8, 2015
  19. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,337
    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.
     
    SunnyChow and dogzerx2 like this.
  20. ensiferum888

    ensiferum888

    Joined:
    May 11, 2013
    Posts:
    287
    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.
     
unityunity