At the very end of my article "Avatars 101" I said I would post an example with a slightly different approach in order to render avatar's transitions.
Well, I have decided to extend the example and split the end result in a series of -most likely- 3 or 4 articles.
For starters, on this article we will concentrate on the transitions' code I promised.
To simplify the explanation a little bit, the whole code to render the avatar is implemented in the Game class (but this is going to change in the third part of the series).
Ok, let's begin ...
1. Create a XNA GS game project on Visual Studio and named it, say, "AvatarGame".
2. Include the following fields (in addition to the ones that are automatically created for you by XNA GS):
The code is self-explainable. Basically, we are adding the basic fields we need to render avatar plus the helper ones to handle transitions.
3. The constructor:
As usual, you must create the managers/services you will use to render the avatars.
But why do we also need two arrays and a random number generator? The latter, in case we want to change animations in no particular order.
And the arrays? Read on …
4. Loading content:
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.
5. Updating the game:
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.
6. Drawing the avatar:
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:
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 …
> Link to Spanish version.