State Transition Limitations

I am becoming quite familiar with how the Mechanim animation system functions, but I am constantly running into the issue that transitions are very finicky to work with due to their limited accessibility. The nature of the game I am working with requires quite snappy input and response, which means VERY often input changes occur during state transitions. Since a transition must finish in it's entirety before moving on, animations begin to lag way behind the input. Naturally, I still would like transitions since they are visually appealing.

Because of this, I am starting to feel like managing transitions manually in code by feeding parameters into blend trees, similar to the solution I proposed in a previous post (http://forum.unity3d.com/threads/different-animations-for-similar-states.282635/#post-1866444) except scaling it to a larger level. By doing this, I have much more control over how a transition functions. For example, I can adjust transition speed dynamically, make a transition reverse part way through, quickly finish a transition (not instantly, but over say 0.1 seconds) to start a new transition. All of these would be useful to me, but I'm not seeing this level of transition control in Mechanim.

The question I would like to ask is this: Is this valid reasoning or am I missing something about Mechanim's transition system? I feel as though by doing this I am simply re-implementing a lot of Mechanim's functionality just to gain additional transition control (which, albeit, is a lot to gain for me).

 

Fighting game?

 

Closer to a beat-em-up I would say, but they are similar enough to warrant the same issues. I'll be honest, I have it mostly working. Combos work just fine, for example, because they are designed to not occur during transitions. It's just small things where other actions occur close to each other that creates visually unappealing animations due to the animations lagging behind, which also makes input feel sluggish.

The shorter I make transitions, obviously the better the situation becomes. However, I don't really like this as a solution. I would like to have transitions as I please. Do you think I am relying too much on transitions to create state changing animations? Should I be animating state change animations and having almost non-existent transition times (such as a crouch-to-stand animation)? I feel this is also very limited because often enough the transition creates a good enough animation that I would be happy to use it.

 

Can you provide a small video demonstrating what you think isn't acceptable, and what you think may be acceptable.
Or you could give a similar game example how you would like it to look and feel.

I think for a game like you have described controls are extremely important to how the game feels.
But I'm also one who wants the game to look as awesome as it can.

Sometimes when were the only ones to see our stuff every day upon day, for so long we scrutinize the littlest things to death!

 

I have custom transitions in script currently working right now which uses blend trees to blend appropriately, and a state machine that works similar to Mechanim except with improved transition control, but I will explain my issue because I would still prefer to use Mechanim if I could get it working as I would like. I have attached the scripts if you would like to see; they can be extended with time to add more transition options.

A basic scenario that illustrates the issue is tapping movement briefly. The animation must fully transition to running, and then transitions back to idle. This makes the character move only slightly (correct) but the animation runs on the spot for a brief time. While this illustrates the issue and does look kinda ugly, it doesn't really cause issues to game play.

Some examples I found while playing were:

• Landing on the ground and hitting an attack immediately after waited for the character to reach idle before attacking, causing the attack animation to lag behind thus throwing off combo timing.
• Moving forward slightly to get in range to attack then attacking, which caused the same issue as above in which the attack animation only starts once the run has transitioned to idle.
• Jumping as soon as the character becomes grounded waits for the appropriate ground animation (idle or run) then transitions to jumping, causing the player to bounce and then perform the jump animation mid-flight.

As you can see, most of the sync issues occur when inputs are put in just after a state change.

Of course, while these are game breaking issues since animation is a major form of player feedback in combat, there are other issues I discussed. For example, I use two blend trees and transition between each of them to perform smooth combo transitions. However, I cannot dynamically change the transition speed to make it transition slower for slower attacks, and faster for faster attacks. This makes slower attacks feel very jerky as they quickly transition to the start and then continue slowly. With the custom transition script I made I am able to decide the transition speed dynamically.

 

Great explainations chazney.
I am offline right now and probably for the rest of the weekend so I cant set up an example system to explain better or view the scripts.
I'm a staight up animator with extremely limited code knowledge though I am able to read them and usually disern whats happening.

Additionally Ive been in 3D Max for nearly 3 months so Im pretty disconnected from mecanim in my mind at the moment.

With that said one thing you mentioned - it seems everything has to transition back into idle before performing another action.

I think you may be able to fix this with "any state". Right?
Instead of having to go back into idle to perform the next animation couldnt it go into any state and transition directly into the next action without hitting idle?

The person to ask on here is the man who is a PRO with mecanim - mecanim.dev.
Hope he doesnt mind me mentioning him to give the definate correct answer.

 

WALL OF TEXT, PROCEED WITH CAUTION OR JUST READ THE LAST PARAGRAPH

That is correct. Idle takes quite a high priority since it is transitioned to when the player's speed is 0. Any state would most certainly work, but transition conditions can get strange to manage, certain animations can't actually be transitioned to from any state, such as ground based attacks. Also, I read somewhere that any state transitions are all evaluated every frame (which makes sense) and can cause needless performance issues. I am wanting to try and avoid that and use it for it's true purpose: transitions that can occur from any state.

I have read about atomic transitions somewhere, in which if you make a transition not atomic, a different outgoing transition can take over. For example, if a transition from idle -> run is active and an attack is pressed, the transition from idle -> attack will take over. However, I played with atomic transitions and I couldn't seem to get the results I wanted. It also doesn't solve the issue of a transition returning to itself, such as the idle -> run -> idle example I explained earlier caused by tapping the movement button really fast.

I will be shifting over my animations to my scripted animations tomorrow, so I can try making a video showing how it is working to better explain what I actually want out of transitions. The main gist of it is that I have a normalized transition float parameter that blends the animations from 0f to 1f. When a state change is detected, it figures out how to set up the new transition based on where the current transition is. For example, if it detects that the target animation is the same as the current source animation, it simply reverses the transition. So if the transition has gone from 0f -> 0.73f, the new transition will become 0.73f -> 0f. If the animation is different, the AnimationTransition.TransitionInfo class will contain information about how the transition should be handled. For example, it might tell the transition to finish itself over 0.2 seconds, then start the next animation 0.2 seconds in to prevent the animation from falling 0.2 seconds behind. Using the previous example, it would go from 0.73f -> 0.90f, where 0.90f is 0.2 seconds into the next animation (2 seconds of transition total), then transition from 0.90f -> 0f. I don't expect you to fully understand this, but you can see just how much control I would like over state changes mid-transition.

As I said though, I will try and get a video once everything is shifted over to my scripted animation engine to explain what it aims to achieve. It uses Mechanim blend trees, so it should be quite easy to visually see how the transition is being handled by looking at the blend trees and the game video output.

 

Oddly enough I believe I understand exactly your desired outcome.

May want to consider packaging up your script transition engine for use by non-programmers, with public inputs in the inspector and release it on the asset store for a reasonable price.

I bet a couple 2-400 people would pay to gain the added transition ability without the complication of scripting it.

Look forward to seeing your example!

 

Sorry to butt in but, could this be avoided by making the animation in Max and then writing your own script. I've not started scripting for animations yet so I don't know much.

 

Not sure I'm understanding all of the issues here, but would such an animation script be like this one?

 

Good catch @hopeful, though I don't know if mecanim control does anything beyond what is currently do-able in mecanim out of the box now, EDIT- beyond exposing some of the code in the inspector for non-coders.

@hopeful - I am pretty sure Chazney is using externally created animations. The base problem - as I understand it - is he wants to have ultimate control of transitions from one animation to another without - for lack of a better term - a jump cut.

Think of mortal combat or any beat em up - but with smooth quick transitions. A lot of fighting / brawler games take considerable 'creative' control to get the movement and transitions down perfectly. And even more of these games don't try to make smooth transitions - rather they find it acceptable and part of the art style to have jump cuts from one animation to the other. This process leans more towards giving the player the tightest controls possible but reduces the fidelity of the animation transitions.

A lot of games have a motion flow which doesn't allow the player character to transitions from maybe standing idle to maybe back flip jump land which is caused by a strong attack from one particular enemy. With a fighting game or brawler type game the transitions need to be able to come from any state to any other state.

@Chazney May want to dig a bit into the universal fighting engine thread.
http://forum.unity3d.com/threads/released-universal-fighting-engine.218123/
There's a lot of information up there for a person to dissect and utilize.

 

I'm not working on the animation area of my game now, so I feel like a lot of my previously acquired mecanim info has drained out of my brain (replaced by my current issues) ... but I'm wondering if you read the part of the Mecanim Control thread that talks about using hidden Unity libraries that you can use in the editor, but which aren't yet available for publishing.

Is that the feature that is sought? If so, it simply may not be available till sometime later in the U5 cycle, and it probably wouldn't hurt to send a note to the Unity devs to get it moved up on the list of things to do.