Saturday, October 18, 2014

Havok Animation

Run time animation systems are one of the most important components in early games. Animation can have effect on different functional aspects of a game including visual, control, game design so a robust animation system  is needed for any game engine. For this reason traditional and in house game engine developers work hard to provide a good and well designed animation system. For example Unreal engine 4 has a good and robust animation system which includes many features like state machines, different animation blending techniques, motion retargeting IK and so on. This is true for Unity3D animation system a.k.a Mecanim.

But in this article I want to have a short introduction on Havok Animation Tool or you may know it as Havok Behavior Tool. Havok animation tool is a robust animation middle ware based on Havok Animation SDK. The havok animation tool provides many great functional and non functional features needed for run time animations like:

  •  Different animation blending techniques.
  • Inverse kinematics.
  • Rich animation state machines with ability to reduce state machine complexity.
  • Ragdoll and keyframe animation blending.
  • Pose matching
  • Animation retargetting
  • Root motion extraction
  • Great peformance
Havok Animation gives you control on many different events which can occur within an animation system. The animation system is very robust and well designed and it's very great at performance. 

In comparison to Unity Mecanim and  Unreal animation system, I prefer Havok animation. The Havok animation tool is a standalone software and it's not usually comes out within a game engine, so you need to integrate it with your engine if you want to have it there. However Havok Vision engine has already did that and integrated it into the engine. You can get Havok vision and Havok animation tool free via Project Anarchy tool sets (free for just mobile development)

For this reason I want to write an article about some features of Havok animation in next posts.

Saturday, March 29, 2014

Motion Planning Project #1

I'm working on a  motion planning project. In this post I placed the first video of the Motion Planner which I'm working on. The motion Planner uses a fuzzy control system to avoid obstacles and reach a specified goal. 37 fuzzy rules are defined on three different parameters to control the speed and direction of the agent.

The system is still immature. It's going to be combined with some machine learning techniques to enhance its performance but for now it just contains a fuzzy motion planner and the animations are few.

There are sets of parametric animations which their parameters are changing based on the commands come from the motion planner. For now the motion planner just controls the speed and direction of the agent.

As you can see in the video the agent is not always find the best and shortest way through the goal because it has no previous knowledge about the environment and it is exploring the environment while going through the goal. This technique has some pros and some cons.


The agent with the same fuzzy rulebase can avoid obstacles and reach the goal in different environments with different arrayed obstacles and no preprocessing phase is needed as you can see in the video.


The agent doesn't have any previous info about the environment and it can't find the best and shortest path through the goal.

The system performance should be improved after I add more animations to it and integrate it with some machine learning techniques. In my next posts I will update some other videos and share the progress of the work here.

Here is the video:

Wednesday, January 15, 2014

Shadow Blade

I just want to introduce the latest announced title of Dead Mage named Shadow Blade which is released on mobile and tablets recently. I worked on animation pipeline for this project. As animator I created the animations and integrated the animations to be applied in designed combat. As a technical animator I organized our exporting pipeline to be used in Unity3D engine because this was our first project using Unity and on the animation programming side I worked on motion extraction and a bit on animation blending. So in next posts I try to focus more on different animation blending techniques and also on motion extraction.

Here is a gameplay video of the Shadow Blade:

Monday, September 2, 2013

What Is a Binding Pose in Character Animation?

Modelers always model 3D models in a pose known as T-pose where the character model stands in a certain pose and the hands and body shows a figure like T (Figure1)

                                                                      Figure1: A 3D model in T-pose and bones placed in it

Modelers model the characters in T-Pose til the riggers can rig the character more easily. This helps them to place the bones and adjust vertex weights and envelopes easier. When all the bones are placed in the 3D model and the skinning process starts, the current pose of the skeleton is saved. This pose is called Binding Pose. The name shows the whole story. Binding pose is the pose where you start binding a mesh to its corresponding skeleton.

Now why a binding pose should be saved ?  You might know that all of the vertices positions initially should be calculated in modeling space. A skinned mesh's vertices are transformed by it's corresponding skeleton. When the skeleton bones transforms, the vertices' positions change based on the weights they have for each bone (bones transformations are calculated in mesh's modelling space (object space)). Now if the vertices' positions change based on the orientation of the bones the whole mesh will be distorted because of an extra orientation or maybe position the riggers made to bones for adjusting bones in meshes. The rigger transforms each bone to fit them in the mesh's body. These transformations (call it Binding Pose Transformation) should not be calculated for the final vertices positions. You can consider an example in which you have a skinned mesh, so by changing bone transformations the vertices positions should be changed. Lets consider just one bone rotation. The orientation of the bone in mesh's modelling space is equal to:

Bone Orientation = KeyFrame Rotation * Binding Pose Rotation

If vertices get affected by the Bone Orientation, first they will be rotated by Binding Pose Rotation and next with the key frame rotation and that binding pose rotation will distort all of the vertices because the initial model that the modeler created is affected by some extra unnecessary rotations. So for bones belonging to a skeleton of a skinned mesh a reference pose have to be saved and this reference pose is called Binding Pose. It will be saved when you apply a skin modifier to your mesh or in other words when you start the skinning process. For each bone in character animation, all of the key frames are stored relative to its binding pose. All of the vertices positions are calculated in the space of their corresponding bones' binding poses. Now for a skinned mesh, deformations occur based on the relative transformations of each bone to its binding pose. This will prevent the mesh to be distorted.

For animation blending each bone has a weight. The weight is ranged between 0 and 1 which 1 means the full calculation of the key frame transformation and 0 means the binding pose. Now any other number between 0 and 1 for a weight shows a blended transformation between bones binding poses and key frames transformations.

Friday, June 21, 2013

Blending Between Walk and Run Animations

In most games, walk and run animations can be blended together by holding analog stick. Depending on how much analog stick is pressed, two animations (usually walk and run) start blending. There is a problem for blending between walk and run animations and that is these two animations has different timings. Blending between walk and run results an unexpected motion. In this post I want to talk about how we can blend between two animations with different timings like walking and running.

Before going further, let’s consider human jogging. Jogging is a movement between run and walk. It's not as slow as walk and not as fast as run. We can say that jogging is partially run and partially walk so the gait and hands should not move as long as they move in running and should not move as short as they move in walking. We can say that the transform of bones are averaged between run and walk in jogging. That's actually what we are doing in animation blending. Obviously, animation blending is a weighted average of different animations keyframes. So for now we know that jogging actual poses can be achieved by blending between run and walk animations. One another thing should be considered is that jogging speed value is also between run and walk speed. This means that jogging is slower than run and faster than walk. To achieve a jog animation by blending between walk and run, we also need to blend between speeds of two animations.

Now let’s consider how we should blend between walk and run to make a jog animation. First it comes from animators. They should animate walk and run with same normalized time. For example, if in walk animation, left foot starts planting on the ground at normalized time 0.5 then the left foot in run animation should start planting on the ground at normalized time 0.5 too and if the right foot in walk, starts planting on the ground at normalized time 0 and 1 (loop poses) then the right foot in run animation should start planting on the ground at time 0 and 1 too.

After making walk and run animations with the rules I mentioned, you can blend the speed of two animations with the same blend factor used for animation blending:

a = blend_factor        where  0 <= blend_factor <=1

T1 = walk_length     (in seconds)

T2  = run_length       (in seconds)


At the most times we need to blend animations with each other linearly so if we use linear animation blending then we need to blend speeds of walk and run animations linearly. For this reason I wrote a linear equation to show the time length of jog animation:

jog_length = (T2 -T1)  * a + T1       where jog animation is the result of blending between walk and run animations with blend factor ‘a’ linearly and jog_length is the time length for jog animation.

At the final step we should change the playback rate of both walk and run animations to achieve a blended speed:

Walk.PlayBackRate = T1 / Jog_length
Run.PlayBackRate = T2 / Jog_length

For avoiding some problems like round-off errors in floating points you can set the Run.NormalizedTime to Walk.NormalizedTime instead of setting the Run.PlayBackRate.

Make sure to change the speed of both animations before calling your blend function, otherwise you will face unexpected results.

Thursday, May 16, 2013

Some Important Features of unit Quaternions for Animation Programming

In the previous post, Euler angles and Quaternions were compared and some important reasons which causes the unit Quaternions to become the dominant rotation system in graphics and game engines were studied. Now we know that we can't run away from quaternions if we want to become an animation programmer, gameplay programmer or graphics programmer, so lets check out two important feature of quaternions.

First lets check out the multiplication of a quaternion to a vector. One vector can be transformed by being multiplied to a quaternion. This multiplication can both scale and rotate the vector. If we multiply an unit quaternion to a vector, it just rotates it and no scale occurs. This is why all the graphics and game engines normalize quaternions before multiplying it to a vector. So after normalizing a quaternion, a vector can be rotated with this equation:

Result = q * v * inverse(q);

Where q is an unit quaternion and  v is our vector which we want it to be rotated and Result is the vector v after being rotated by q. One most important feature of quaternion multiplication is that it's not commutative. So q1*q2 is not equal to q2*q1. This order of multiplication is really important for many animation algorithms like animation blending techniques. For example you can seek the importance of this rule in additive animations. Additive animations are one type of animation which are the difference of at least two animations. Mostly they are used for asynchronous events. For example you can create a breathing additive animation in which only character's spine bone is rotating in and out and other bones have no transformation. This additive animation can be added to any animation like idle aiming, running and many more. Now if we want to add an additive animation to an existing one, we should notice about the order of quaternion multiplication. First the main animation should be calculated, then the additive animation comes up on it so the rotations should be calculated in this order.

Now let's consider a simple example in which q1 is the rotation of main animation and q2 is the rotation of additive animation. the order of additive animation blending should be like this:

1- First apply q1 to the current vector (v) :
 Result1 = q1 * v * inverse(q1)

2- Second apply q2 to the Result1:
Result2 = q2 * Result1 * inverse (q2) = q2 * q1 * v * inverse(q1) * inverse(q2)

So you can see if you want to add an animation to another you have to multiply them in reverse order like:


This means your vector first rotates by q1 and then q2, q3 ..., qn

Just note that most of the graphics and game engines overload the quaternion-vector multiplication  with operator '*', so you can replace the 'q * v * inverse(q)' with just 'q * v'.  If you are using an engine or API which has overloaded quaternion-vector multiplication then you can apply the multiplication order mentioned above, like this:


Now lets consider another important feature of unit quaternions. You can consider the imaginary vector part of a unit quaternion as the axis which your vector wants to rotate around and the scalar part is some value shows the amount of rotation around that axis. The imaginary vector part has a great feature and that is, its magnitude is equal to sin(a/2) where a is the rotation degree or radian which you want your vector to rotate around the imaginary vector part of your unit quaternion. Also there is another important feature for unit quaternions and that is the the scalar part is equal to cos(a/2). So whenever you want to create an unit quaternion which can rotate your object around an axis [x,y,z] with a degree equal to 'a', you can follow these steps in order:

1- First normalize your rotation axis:

 [x,y,z]/ length( [x,y,z] )

2- Multiply the normalized rotation axis to sin(a/2) and use the result as your imaginary vector part.

3- Use cos(a/2) as your quaternion scalar part.

Now for a better understanding, lets consider an example in which you want to rotate your object around y-axis with 90 degrees. First you have to normalize your rotation axis which is [0, 1, 0]. In this example, our rotation axis is already normalized so we should not normalized it again. Second, we should create our imaginary vector part by multiplying the rotation axis to sin( 90/2 ):

sin (90/2) = sin (45) = 0.7071

Imaginary vector part = [0, 1, 0] *0.7071 = [0, 0.7071, 0]

At the third step, we should calculate the scalar part of our quaternion which is equal to cos (90/2):

w = cos (45) = 0.7071

The final quaternion should be like this:

[ 0.7071, 0, 0.7071, 0]

You can write it as its mathematical form:

0.7071 + 0i + 0.7071j + 0k = 0.7071 + 0.7071j

This can be considered inversely, for the times you have an unit quaternion and you want to know how much it can rotates your vector. In this situation, for finding the desired degree you can do this:

DesiredDegree = 2 * ArcCos(w)

Don't forget that a unit quaternion can just rotate an object between 0 and 180 degrees because it uses ArcCosine function to represent rotations. So if you want to rotate an object more than 180 degrees through time, you have to do it with more than one rotation. For example if you want to rotate your object with 240 degrees linearly through time, you can first Slerp it it with 120 degrees at t/2 and after that, Slerp it again with another 120 degrees at next t/2.


Most of the game and graphics engines use unit quaternions for rotations. Learning to work with them is very important. Some people prefer to use Euler angles for rotations because they are most understandable but the fact is that the used graphics or game engine converts Euler angles to an unit quaternion because of the reasons i mentioned in this post. So by working directly with unit quaternions the conversion step of an Euler angles rotation to unit quaternions can be omitted.

In this post two important feature of quaternions and unit quaternions were considered. These two important features are using frequently in Animation, Gameplay or Graphics programming so its good to keep them in mind.