Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#Actualhaegarr

Posted 28 October 2013 - 04:23 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 ...


#1haegarr

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 much 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 ...


PARTNERS