Jump to content

  • Log In with Google      Sign In   
  • Create Account


Animation state machines


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 RobMaddison   Members   -  Reputation: 657

Like
0Likes
Like

Posted 06 January 2014 - 07:51 AM

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

Sponsor:

#2 morbik   Members   -  Reputation: 363

Like
2Likes
Like

Posted 06 January 2014 - 08:33 AM

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.


Edited by neonic, 06 January 2014 - 08:36 AM.


#3 rpiller   Members   -  Reputation: 666

Like
0Likes
Like

Posted 06 January 2014 - 09:45 AM

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.



#4 RobMaddison   Members   -  Reputation: 657

Like
0Likes
Like

Posted 06 January 2014 - 09:52 AM

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.

#5 RobMaddison   Members   -  Reputation: 657

Like
0Likes
Like

Posted 06 January 2014 - 10:11 AM

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.

#6 rpiller   Members   -  Reputation: 666

Like
1Likes
Like

Posted 06 January 2014 - 10:25 AM


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.



#7 RobMaddison   Members   -  Reputation: 657

Like
0Likes
Like

Posted 06 January 2014 - 11:25 AM

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.[/size][/size]

 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.[/size] 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.[/size]

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

#8 rpiller   Members   -  Reputation: 666

Like
0Likes
Like

Posted 06 January 2014 - 11:41 AM


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 smile.png


Edited by rpiller, 06 January 2014 - 12:34 PM.


#9 warnexus   Prime Members   -  Reputation: 1399

Like
0Likes
Like

Posted 06 January 2014 - 12:07 PM

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.

 

 

 



#10 rpiller   Members   -  Reputation: 666

Like
0Likes
Like

Posted 06 January 2014 - 12:25 PM

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.


Edited by rpiller, 06 January 2014 - 12:25 PM.


#11 haegarr   Crossbones+   -  Reputation: 4173

Like
1Likes
Like

Posted 06 January 2014 - 01:30 PM

It is okay to have explicit transitional animations. The idle animation and the walk animations have no motion phases in common, so blending as a whole (i.e. separate blending of single body parts isn't available) could introduce irregularities. Maybe one can live with them because they are short in time or mostly not visible by some other reason.

 

An explicit transitional animation would get its own state if modeled in an animation state machine. That state will be left after the transitional animation has completed, either controlled by elapsed time or (perhaps better) controlled by a trigger event fired from a respective track of the animation.

 


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

The term "state machine" is generic for a couple of things. You're right w.r.t. a simple state machine. But there are other incarnations, too. For example, in a hierarchical state machine (HSM) one has concurrency, so that several states can be active in parallel. However, I've not seen a HSM in use for animation as discussed in this thread.



#12 RobMaddison   Members   -  Reputation: 657

Like
0Likes
Like

Posted 06 January 2014 - 02:46 PM

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.

I think perhaps I didn't explain myself too well. I'm talking about the level above the animation blending. I see the configuration of [3d] animation as hierarchical. At the lowest level you have animation clips. Above that you have clips which are blended/layered together (with the 0-1 factor you mentioned) and above that, a state machine to handle everything from an action perspective.

So for example, lets say we have these player states:

Idle
Walk
Shoot
Die

In a very simple system, you may have an animation system which doesn't do any blending and just runs each animation depending on which button is pressed. This obviously wouldn't look too realistic.

You then may have a system where you decide to incorporate a simple blend between each state. This would look more realistic but isn't very scalable for more complex movements.

The you can have a more generic and scalable system and do both animation tree blending and blending between states. So you could have a situation where you have the animation clips that when blended together give you a state. For example, imagine an animation where the player has hurt his leg and is limping. This works well for the normal player but you might have a zombie style walk and if you blend the hurt leg walk with the zombie walk, you get a zombie with a dead leg! This would constitute a walking state still.

So you can combine all these different animations to make different, organic and interesting motions but they are still states in themselves. Eg zombie walk, zombie injured walk, normal walk, normal injured walk, etc.

Above this level is the state manager. So you can easily apply the following states in some script:

Zombie_idle
Zombie_walk
Zombie_shot_in_leg
Zombie_idle_anguish
Zombie_walk_with_limp

The anguish the zombie is experiencing could come from a generic anguish animation but when combined with the zombie idle, it adds a unique flavour.

So in order for these states to look organic and realistic, you would also need to blend between the states themselves so you can see we've got two levels of blending going on. The animation state machine transitions would store default and overridable blend factors for cross-fading/immediate switching, etc.

You could get more complex if you like by blending even more base animations and/or using difference animations for a really organic feel, with such a configurable system, the possibilities multiply exponentially.

I think my original question has been answered by pretty much all of us really, myself included. It was more about what type of animation should be considered as a state. Like walking is a repeating animation and a continual state (as long as you keep doing it obviously), but going from idle to walking is not, it's a one shot thing. I just wanted to clarify that this particular in-between 'motion' should be classed as a state - and I think the answer is yes.

Edit: and as I just saw, confirmed by Haegarr ;-)




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS