I think I know the answer to this question already but I just wanted to make sure I'm in the right track (no pun intended)...

I'm creating an animation state machine and I've done some research on it. The only thing I'm not fully clear on is how to handle transition animations within the state machine. I don't mean the transitions between states, I mean between the actual animations. Would these, themselves, be classes as full states?

For example, my character is in the 'idle' state and the user has pressed a button to make him walk forward. I have a small animation which is between standing and walking. At the end of this small animation, there is no blending, it just snaps straight into the walking cycle. There will, however, be a small amount of blending between the idle state animation and the 'start walking' animation.

I'm assuming I'd need three states here:

Idle
Start walking
Walking

Does this sound right? I wasn't sure whether, as the 'start walking' state wasn't a looping state, it might be considered as some kind of transition state or something.

I know I can blend between idle and walking but I prefer the more realistic feel of the start as well, it does look better.

Thanks

This may not be the perfect solution, but what I'm reading of your system, to me it makes sense to refactor it a little bit. I wouldn't have concrete classes representing states during the "transition" between two animation states. If I were designing a system like this, I would likely create a generic class to describe properties of the animation. I would also include several transition types... a cross fade blend, a directional blend, etc. These would operate on two AnimationStates: from & to. It could accept information such as duration, weights, curves, etc.

Then just do the operation until duration & set the final resulting AnimationState at the end.

Edit: I think your question, upon re-reading it, may have been more about making the animation sequence look polished. I would have an Idle, idle_to_walk, walk_to_idle for starters. When you start walking your weight shifts forwards slightly, and when you stop, you will shift your weight backwards a little bit. The effect is exaggerated when running. Hope this helps, even a little bit.

Why do you have an animation between idle and walking? You should be able to just blend out the idle over time while at the same time blend in the walk to get this functionality.

I work in an engine that handles blending for me (I just pass a 0-1 blend value to the animate function), and what I do is store all my animations in a list. Then I have a list of this list which is the "layer" the animations reside in. The layer is used for split animations. Layers are played from 0 - N. I add all my animations at the start and they all have a blend value and enabled flag. I look through all animations every frame and if the animation isn't enabled (most aren't at any given time) it just skips over it. If it is enabled it does the blend where if blend direction is + it caps out at 1 and if neg at 0. When I set animations it checks to see if that animation is the current one already and if so does nothing. If it's not the current one then it makes the current animation blend direction neg (so it starts blending out) and resets the new animation and enables it so it starts blending in.

With the multiple layers I put things like my shooting animation in a higher layer and my running, walking, strafing in the lowest layer. So what ends up happening is that I can shoot on the upper body while running, walking, idle, etc. I then don't need so many animations in my model.

I also do bone rotation via code so when the player runs forward AND strafe it rotates the hips a little and upper body by a little less to give a nice effect. You can do this when they turn as well to get a more realistic turning as normally if running and turning the body leans some to that direction.

I,however, don't do this in a state machine, but just a bunch of if statements at this time. What does your code look like right now with a state machine around this? I would be interested to see it. I generally only use state machines for higher level switching between major game states (logo, main menu, lobby, game). These states generally don't have a ton of dependencies between each other and I just find "sub" state machine states need to know a lot about other parts of the running game and haven't found a good way to give access to that info from within each state.

This may not be the perfect solution, but what I'm reading of your system, to me it makes sense to refactor it a little bit. I wouldn't have concrete classes representing states during the "transition" between two animation states. If I were designing a system like this, I would likely create a generic class to describe properties of the animation. I would also include several transition types... a cross fade blend, a directional blend, etc. These would operate on two AnimationStates: from & to. It could accept information such as duration, weights, curves, etc. Then just do the operation until duration & set the final resulting AnimationState at the end. Edit: I think your question, upon re-reading it, may have been more about making the animation sequence look polished. I would have an Idle, idle_to_walk, walk_to_idle for starters. When you start walking your weight shifts forwards slightly, and when you stop, you will shift your weight backwards a little bit. The effect is exaggerated when running. Hope this helps, even a little bit.

Thanks. I think what I was getting at was along the lines of what you said. The start-walking 'state' would actually be an explicit state in itself. The start of that state would be a blend from the previous state (I.e. idle) and the transition to the next state would be a direct switch.

Why do you have an animation between idle and walking? You should be able to just blend out the idle over time while at the same time blend in the walk to get this functionality.

My walking animations are recorded from the end of my idle animations. So as it's only 20 or so frames, why not include the animation from idle to walking. tp me it looks more natural and as neonic mentioned, it's more realistic because of weight shifting.

What does your code look like right now with a state machine around this? I would be interested to see it. I generally only use state machines for higher level switching between major game states (logo, main menu, lobby, game). These states generally don't have a ton of dependencies between each other and I just find "sub" state machine states need to know a lot about other parts of the running game and haven't found a good way to give access to that info from within each state.

I'm still at the design stage so not much to look at yet. At this time I essentially have animation building blocks upon which I'd like to use an animation state machine to easily control the motion flow. I can already blend and layer animations together but I need something to separate that and control is easily from the game logic/scripting.

Essentially each state has an animation sequence linked to it which will be built by a data-driven configuration of blend animation trees. So an example of states might be:

Idle
Idle_to_walk
Walk
Walk_to_idle
Idle_to_die

As per a normal state machine there will be a graph of nodes allowing the flow between each of these nodes to be constructed (in text form). Each transition between nodes will have some metadata about how the state change is achieved visually, eg blending, immediate switch, etc

The idea that it's all completely data driven is the most pertinent here I think.

My walking animations are recorded from the end of my idle animations. So as it's only 20 or so frames, why not include the animation from idle to walking. tp me it looks more natural and as neonic mentioned, it's more realistic because of weight shifting.

I would think the walk animation has the weight shifted forward some itself and so blending between idle and walking would show that weight shifting. That's how it works for me when I blend anyway. If you blended you could possibly remove the transition states and push the new state on an active states list, and run both the old state (while blending out) and the new state (while blending in and keep it running until you switch). Once the old state is fully blended out it then gets removed from the list. It would just be a modified state machine specific to animation since it would need to run 2 states at a time while transitioning. Just a possible solution.

I just mention this because I purchase my models and most don't have animation transitions like you talk about because I think programmatically blending is very common and generally accepted. That's my experience anyway.

My walking animations are recorded from the end of my idle animations. So as it's only 20 or so frames, why not include the animation from idle to walking. tp me it looks more natural and as neonic mentioned, it's more realistic because of weight shifting.

I would think the walk animation has the weight shifted forward some itself and so blending between idle and walking would show that weight shifting. That's how it works for me when I blend anyway. If you blended you could possibly remove the transition states and push the new state on an active states list, and run both the old state (while blending out) and the new state (while blending in and keep it running until you switch). Once the old state is fully blended out it then gets removed from the list. It would just be a modified state machine specific to animation since it would need to run 2 states at a time while transitioning. Just a possible solution. I just mention this because I purchase my models and most don't have animation transitions like you talk about because I think programmatically blending is very common and generally accepted. That's my experience anyway.

I think the main idea behind state machines is that you generally are only in one state, otherwise you'd need something above it again to control which state(s) you're in

I think the main idea behind state machines is that you generally are only in one state, otherwise you'd need something above it again to control which state(s) you're in

There is already a state manager that needs to exist to handle all the states (at least that's the way I've worked with states). That would be the part that controls which state you are in and how to transition between states. When you switch statesthe state manager could hold the last state and not run it's logic for state transition (since you've already transitioned) but still update it's animation and blend it out. The state manager could then check the last state each frame and once it's fully blended stop doing anything with it.

My state manager already keeps the last state so that I can do a stack sort of thing if I want to. While inside a state I can do a Pop() on the state manager to get out of the current state and back into the last state. You wouldn't need to do this for animation, but just saying, the state manager can store the last state you were in pretty easily and even do something special with it in it's Update() method. This is why I was saying a slightly modified state machine for animations as they generally have a little different requirement for transition because of blending. Most other cases of a state machine probably don't have this special requirement.

If you really wanted to keep those transition animations you could still do that and use a modified state machine like I mention to even blend between those. State machines don't automatically fit nicely into every problem and slight modifications are OK. The standards police won't arrest you

What do you mean by blending? Do you mean like "in-betweens in animaton?" You don't need the "blending" to do the transition. It is just drawing the appropriate animation depending on the state of the character and the direction of where the character is facing.

The way I implement my animations for my main character would be drawing the appropriate animation depending on what direction the character is facing and what "state" he is in.

Example: if state is running and direction is left, then draw the running left animation, otherwise checking the other state and their direction, then draw the appropriate animation for that state.

My posts (and I assume the OP) are about 3D animation not 2D. I guess the original post doesn't say one or the other. In 3D if you just play the animation without blend it'll look bad and jerky, unless you have specific transition animations, which can be wasteful/costly/time consuming to make all transition animations. So in 3D, when you go from idle to walk, you want to play both animations on top of each other, but you have a blend value ranging from 0 to 1. Before you walk you are only playing the idle animation with a blend value of 1 (fully blended in). Then you press a key to move forward and you now play the idle and walk animation but you start reducing the blend value of the idle animation from 1 to 0 and the walk blend value from 0 to 1. This creates a very smooth transition between the 2 animations and doesn't require any special transition animations to exist.