Runevision's Locomotion System for Mecanim or the Animator Controller ? [Advice Needed]

I need advice on which system to use as a main locomotion system in my game: Rune's Locomotion system or using the current work flow of states/blend trees with the animator controller.

Long story not-so-short: I have spent the better part of the last two-ish weeks on converting the system to Mecanim. If you recall, the system uses the legacy animation component. Therefore, until recently, the system was unusable with Mecanim. Below are some of the reasons why not:
1. You can't add clips/states on the fly.
2. You can't control animation states directly (moving to a random time inside a state and play from there, stop, rewind, etc..)
3. You can't control the blending of random clips/states (They have to be connected, inside a blend tree, etc...)
4. The list goes on....

With the incorporation of playables, this became possible, and now I have the system playing mecanim/humanoid animations on top of the animator flawlessly. However, I am perplexed: Should I use it ? I mean it is up to date now, but what if the animator controller can do everything the system does without all the hassle. Here are some of the selling points of the system, and the counter arguments for the animator controller (AC):

1- The system has a complex algorithm to blend animations with exact blend times | AC has blend trees and they are decent, but needs somewhat similar foot alignment (run and walk hit the ground at the same normalized time)
2- The system is easy to setup, just drag/drop the animations | Well setting blend trees in AC isn't so difficult either.
3- The system has an IK foot placement | Plenty of assets that also does that so not a problem for AC

I really really like the system, but the same goes for AC. However it's somewhat old (made back in 2010), still pretty advanced, but if AC can handle everything it does, I'd like to go the AC route.

If you have experience with both systems, I would like to know your opinion or feedback

Thanks
Fayad

 

LSS. Mecanim.

 

mmm, I see, Thanks ...

 

Do yourself a favor and write an Ik handler using Mecanim IK. For handling states make a set of bools and matching strings that match the Mecanim state names. When switching states in code just pass the bool to the iteration loop and turn off all states except the one that is true by passing the matching indexed strings to Mecanim. This saves all the hassle with their hashing system. I you want to know what state you are in just look for the boolean switch.

 

I'd also go with Mecanim.

Stuff that's marked as "legacy", like the old animation system, is being kept around mostly for compatibility with old projects, so I wouldn't start something new with it unless it was the only option for some reason. The thing could still be perfectly good as far as functionality is concerned, the issues are that it's probably not getting the same level of support as its replacement, and there's the risk that it'll actually get removed, potentially impacting your access to updates/patches/fixes.

 

I don't think he's talking about keeping the legacy system.

He is thinking if he should keep the updated locomotion system he made (which now uses mecanim and playables I guess?), or completely switch to mecanim.

I don't have an answer, but I hate mecanim with passion. It's badly designed and it's abysmal for anything that isn't character animations.

 

Ahhh. I interpreted "the system" as their game's locomotion, which is using one of the two things mentioned. But on re-reading I think you're right, they've converted a 3rd party controller to work with Mecanim, and are asking if it's worth having that system in the middle instead of just using Mecanim directly.

By that interpretation, I have no idea which approach is better.

 

First, thanks for your not so LSS input ... The things of concern for me are not IK nor handling the states with the animator controller (I'll refrain from using the mecanim designation since both approaches use it). For IK I'm using Final IK and a third party asset to handle states, transitions and whatnot.. However, to go a bit into detail, imagine we have a running animation cycle and two stop animations (one with a different leg up at start, let's call them right-down and left-down):

- With the animation controller, normally I would have to make a blend tree (8 direction locomotion) make transition to the two states (state for each leg up), then, the transitions will then need to be chosen based on which leg is currently on the ground. If, for example I stop running and I have my right leg on the ground, I'll transition to right-down. However, if both legs are on the ground, then I need to continue playing the walking cycle until one leg is on the ground (thus not stopping when I want). If I want to make it so the player can stop and then decides that he wants to walk again, then I would also need to make transitions from the two states back into the blend tree, and also make transitions to an idle state. You see how complicated it is becoming

- With the locomotion system, I don't need to concern myself with all this stuff. The system pre-processes all this information at compile time, and during play time, If I want to stop when both legs are on the ground, the system will automatically pick a transition (based on the leg that is currently hitting the ground) and start the stopping motion. If want to re-walk, It will also know which leg is on the ground and start from there. So the system is more responsive. Can this be reproduced with the animator controller ?

The disadvantage is that I need for once to hook up the system to the animator; two, If I want to include non-locomotion animations, then I need to hook up an animator controller (because it has its advantages after all) to the locomotion system, and decide which one should affect the animator.

Sorry for blabbering non-stop

 

@AcidArrow and @angrypenguin, thanks for your input. To clarify, yes I am using playables with the animator (so it's all mecanim, no legacy stuff) I can even hook up the system to an animator controller to play non-locomotion animations. As for performance reasons, non currently observed, but is it the right approach ? (more detail in my previous response). and here's a snap of what it looks like inside Unity.



As you can see, I have the traditional Animator with an animator controller (only used for non-locomotion animations) and the Simple Animation component that acts the same as the legacy system but for mecanim. The simple animation script also has a Special state called controller (not shown) that uses the animator controller as a layer (So I can take advantage of the animator controller if I want to).

 

Ah, not sure. I think it's one of those situations where you'll be the one to tell us, since you're the one making the thing

It'll probably be more expensive than just using mecanim straight up, but it might not be significant, so, I'm not sure.

 

2. you can control animations (move to, stop, rewind) with
[
animator.Play (animname, -1, animtime);

(or even by setting speed directly)

3. you can blend to (don't need to be connected) with

animator.CrossFade (animname, blendtime)

__________________
what you can't do is
jump to an animation time with blending

and there are disadvantages like
you can't see the blending visually like in mecanim transitions

 

You are right in here, what I was thinking about when I wrote my comment was controlling the state with normalizedtime and a weight. The same goes for number 3. you can crossfade from a state to another but you can't control the Weight manually.