As you can see, in this method we populate the array of animations with each built-in available animation for avatars. The reason? We use this array as a cache so as to speed up the look-up process when phasing out from one animation to the next one.

Then, we set-up the initial transition and set the view and projection fields (note: both matrices are always “fixed“ in this example).

There is no significant code for the Initialize and Unload methods, and thus we move to the Update method.

At runtime, if you press the ‘A’ button and no transition is being executed, then you force “the avatar” to start a transition to the next animation.

By pressing the ‘B’ button, you change the way the next animation is selected: in ascending order or randomly.

Notice that when the current animation is about to end, the game selects the next animation, in the current order method selected by the user.

When either the last frame of the animation being played is reached (no looping) or the user forces the transition, we then copy the bone transforms for the position in that animation, reset the position to zero and change the animation to the “target” one.

You may wondering what’s the purpose of the field “transitionStep”. This factor states the time we will spend to move from “the last” position of the ending animation to the “current” position of the starting one.

Why to the “current”? The behavior I decided to choose in order to create a believable look’n’feel for the transition was to avoid going from “last to first” and instead from “last to current” (notice that the starting animation will play from the moment we execute the transition out, and so the current position will change).

Of course that you can change this behavior if you prefer going “from last to first” position behavior before playing the entering animation.

Finally, we call the “CalculateTransition” method which I will explain after the Draw one.

// Draw the current position and length of the animation being rendered.

if ( currentAnimation != null )

{

this.spriteBatch.DrawString(

this.font,

"Processed " +

this.currentAnimation.CurrentPosition.ToString() +

" of " +

this.currentAnimation.Length.ToString() +

".",

new Vector2( 50, 115 ),

Color.White );

}

// Flush the batch.

this.spriteBatch.End();

// As usual, call the base method.

base.Draw( gameTime );

}

The only important code to notice here is the one in charge of rendering either the animation as is, or the calculated transition.

Since the Draw method of the AvatarAnimation expects an instance of type “IList”, we can pass an array of matrices directly without creating a ReadOnlyCollection.

7. Finally, the magic:

/// <summary>

/// Calculates the proper bone transoforms for the current transition.

/// </summary>

privateunsafevoid CalculateTransition()

{

// If so, declare all needed helper primitives.

// For debugging purposes you can use local fields marked as "final",

// which in this example are commented out.

Matrix currentMatrix, targetMatrix;

Vector3 currentScale, targetScale; //, finalScale;

Quaternion currentRotation, targetRotation; //, finalRotation;

Vector3 currentTranslation, targetTranslation; //, finalTranslation;

// For each transform's matrix.

for ( int i = 0; i < this.transitionTransforms.Length; i++ )

{

// Since we are pointing to a managed struct we must use the

// reserved word "fixed" with an "unsafe" method declaration,

// if we want to avoid traversing the array several times.

fixed ( Matrix* matrixPointer = &this.transitionTransforms[ i ] )

{

// Get both, the current and target matrices.

// Declaring these two local fields could be omitted

// and be used directly in the calcs below, but

// they are really useful when debugging.

currentMatrix = *matrixPointer;

targetMatrix = this.currentAnimation.BoneTransforms[ i ];

// Get the components for the current matrix.

currentMatrix.Decompose(

out currentScale,

out currentRotation,

out currentTranslation );

// Get the components for the target matrix.

targetMatrix.Decompose(

out targetScale,

out targetRotation,

out targetTranslation );

// There's no need to calculate the blended scale factor, since we

// are mantaining the current one, but I include it in the example

// for learning purposes in case you need it.

/*Vector3.Lerp(

ref currentScale,

ref targetScale,

this.transitionProgress,

out currentScale );*/

// Interpolate a rotation value from the current an target ones,

// taking into account the progress of the transition.

Quaternion.Slerp(

ref currentRotation,

ref targetRotation,

this.transitionProgress,

out currentRotation );

// Interpolate a translation value from the current an target ones,

// taking into account the progress of the transition.

Vector3.Lerp(

ref currentTranslation,

ref targetTranslation,

this.transitionProgress,

out currentTranslation );

// Calculate the corresponding matrix with the final components.

// Again, in this example, the creation of the scale matrix can be omitted

// from the formula below (you may only use the rotation and tranlsation

// factors obtaining the same result and save some processing power per loop).

//this.transitionTransforms[ i ] =

*matrixPointer =

//Matrix.CreateScale( currentScale ) *

Matrix.CreateFromQuaternion( currentRotation ) *

Matrix.CreateTranslation( currentTranslation );

}

}

}

Every time we need to calculate and update the interpolated transition transforms, we’ll have to decompose the matrices of both, the last position in the ending animation and the updated position in the entering animation.

If the last position of the old animation is “fixed”, why do we need to decompose its matrices every time we call this method? Good question. Short answer: we don’t. We could calculate the old transforms once and store them in a private field for the game, but I include them here in case you want to change the default behavior (for instance, if you decide to keep the ending animation playing as well as the entering one).

What’s with the words “unsafe” and “fixed”? We must declare those two in order to use pointers to value types (plus mark the project to allow unsafe code). Fixing the field will prevent the GC from collecting it until we do not need it anymore, plus, in this case, it will allow us to directly use and set the value store in the stack without traversing the array of transition transforms twice per “for” loop to first get and then update the value type.

Phew! That’s it for now; when you compile and run the program you will see a random created avatar do some nice transitions either when the last animation ends or when you press the ‘A’ button.

You can download an example project for this article from here (you will find an extra class with two extension methods for the AvatarAnimation, named “LastFrameReached” & “RemainingTime”).

You can tweak the behavior and optimize the code a little more (say the rendering, create a specific class for the avatar and so on), or wait for the upcoming parts on the series …