Jump to content

  • Log In with Google      Sign In   
  • Create Account

Animation Blending

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
5 replies to this topic

#1   Members   -  Reputation: 429


Posted 27 October 2013 - 08:45 AM

Hello Everyone

I'm working on a multiplayer FPS game that is fast paced. We have skeletal animation code in place and we can blend from one animation to other when player change actions (like changing from running animation to walking animation). However the problem is that the player can request another animation track (or any number of tracks if she/he is fast enough) while other two animations are blending. I can't simply change new animation with other two while they're still blending.

My initial thoughts was to use a blending weight that takes into consideration previous animations and new one but I don't know how I could implement that or even if its correct.

I really appreciate it if anyone can tell me how other games accomplish this task or any pointers in right direction.


#2   Crossbones+   -  Reputation: 7164


Posted 27 October 2013 - 09:51 AM

Blending is not restricted to 2 arguments. The blending you're doing at the moment is probably a weighting like in

    ( 1 - w ) * A1 + w * A2

where w is in the range [0,1]. This can be expressed as

    w1 * A1 + w2 * A2

and generalized to
    sumi ( wi * A)
with the condition
    sumi ( wi ) = 1
Driving the weights is the job of the animation controller. E.g. the speed variable is used to compute the relative weight of ambling and walking or walking and running. If you have blending on several levels, like blending between different speed forward animations and then blending with e.g. leaning to mix in curve movement, then you have to consider that blending is not commutative. So your animation controller really has to blend the forward movement animations first, then to consider the leaning. Such dependencies are well formulated by a blend tree (in the end it burdens the designer to find a nice looking solution).
Another aspect is whether an animation should override a basic animation. This is called animation layering. E.g. if the avatar aims with a pistol, its weapon arm is no longer controlled by the basic walking animation but by the aim controller. Obviously, such layering need to be done to selected potions of the skeleton only.

Edited by haegarr, 27 October 2013 - 09:52 AM.

#3   Crossbones+   -  Reputation: 2833


Posted 27 October 2013 - 01:33 PM

^ Any common way to tag bones when layering animations such as walk (legs) and weapon swaying (arms) or  it is hard-coded (create some kind of animation controller specialized for humanoid characters)?

#4   Members   -  Reputation: 429


Posted 27 October 2013 - 03:00 PM

Thanks haegarr for your explanation. Yes I'm using weighting formula like yours:


( 1 - w ) * A1 + w * A2


I'm not sure if I stated my question correctly but what I'm looking for is to somehow transition between animations so the player doesn't notice animation change while requesting new animations (3 or more, take a look at example below). We have animation channels so separating bones for different animations isn't an issue.


Say the player character is walking and then starts running. Our current animation code would transition the walk to run animation in 300 milliseconds using the above formula to adjust the weight toward the run animation. So far so good. But the problem starts when user request another animation like crouch in middle of walk to run transition.

#5   Crossbones+   -  Reputation: 7164


Posted 28 October 2013 - 02:31 AM

Our current animation code would transition the walk to run animation in 300 milliseconds using the above formula to adjust the weight toward the run animation.

How do ou do this? There are some possibilities of doing so, and changing animation on-the-fly depends on how above is done exactly. If a pleasing transition is wanted, then both animations walking and running (as an example for this kind of blending) need to be synchronized. This can be done in at least 2 ways.


The first way is to model the transition animation(s) explicitly. One then defines a mark in the walking animation where a particular transition animation can start. When the running mode is triggered, the next mark belonging to a suitable transition animation is searched for, the belonging animation is picked and enqueued as the next to play animation. When the animation system advances the time beyond the said mark, it notices the queued animation, and hence stops the former and activates the latter one; this obviously pops the animation from the queue. The new animation shows a corresponding mark that is used as starting point. At the end of the transition animation there is another mark that is used similarly to sync with the running animation.


Maybe there are no explicit marks but the loop ends are used as such. However, the point is that at special moments during playing an animation another animation can replace the former one. Using explicit marks allows to do so in the middle of an animation, too.


Now looking at walking and running as "modes", one can argue that these are 2 states of a state machine, and the transition from the one to the other is garnished with a nice looking animation, too. IMHO it would be better to look a bit different to this. I.e. see the transition animation as a third state, and let the state transitions take place atomically  as soon as a condition is matched. Doing so makes no difference between a walking or running animation on the one side and a transition animation on the other, allowing a transition animation to have marks functioning as "break points" as well.


To avoid to model too many animations, one may enqueue more than a single animation at a time. Lets say that in the middle of the transition animation is a mark that allows the player to trigger crouching, but there is no "between walk and run to crouch" transition. But synchronizing the transition and its backward transition is often easy. It can be done at several moments, e.g. at 1/4 : 3/4, 2/4 : 2/4, and 3/4 : 1/4 of the durations. So enqueue a the backward transition and its follower transition from walking to crouching.


The second way is to not model the transition between walking and running explicitly, but to adapt both phases (mainly by controlling the playback speeds), and blend them. In this case a continuum between walking and running is possible. Depending on the mechanics of the game, this can be offered to the player or is totally hidden by the animation system. However, it means that there is not a single animation (as in the case of an explicit transition animation) but are two of them at work at a time. But both of them run in parallel due to the mentioned phase synchronization, so working with marks is possible again.


Looking at the both ways, you usually don't have an either or decision, because the second way is nice for animations of similar kind, but may fail miserably for too different kinds. E.g. the transition from standing to walking is a candidate for explicit modeling, and so may (will) be the transition from walking to crouching.


Even if you don't want the effort of synchronization and blend animations without it, the trick with marks can still be done.


Oh well, this post has reached the extent of an epic ;) Time to end it ...

Edited by haegarr, 28 October 2013 - 04:23 AM.

#6   Members   -  Reputation: 429


Posted 28 October 2013 - 07:38 AM

wow! :)


So for best possible transitions we must have intermidiate animations that's triggered in right time. I think I'll have to use the second approach more to reduce the number of intermidiate animations that have to be created.


Thanks again for your time haegarr, much appreciated!

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.