Animation, Walking Between Points, and Basic Quaternions

Ported to VB.NET by Aeauseth


In this tutorial we will be covering how to take an Entity, animate it, and have it walk between predefined points. This will also cover the basics of Quaternion rotation by showing how to keep the Entity facing the direction it is moving. As you go through the demo you should be slowly adding code to your own project and watching the results as we build it.


This tutorial will assume that you already know how to set up a VB.NET MOgre project and make it compile successfully.

Getting Started

First, you need to create a new VB.NET console Application for the demo. Make the necessary MOgre changes as described in Basic Tutorial 0. Replace the contents of Module1.vb with:


Be sure you can compile this code before continuing.

Setting up the Scene

Before we begin, notice that we have a class called MoveDemoClass. There are several variables that hold the entity we create, the node we create, and WalkList will contain all the points we wish the object to walk to.

First we are going to set the ambient light to full so that we can see objects we put on the screen.


Next we will create a Robot on the screen so that we can play with him. To do this we will create the entity for the Robot, then create a SceneNode for him to dangle from.


This all should be very basic, so I will not go into detail about any of it. In the next chunk of code, we are going to tell the robot where he needs to be moved to. The VB.NET Queue variable type is a First in Last out (FILO) object. The Enqueue method add an object to the bottom. The Dequeue method removes it from the top. This code adds two Vectors to the queuee, which we will later make the robot move to.


Next, we want to place some objects on the scene to show where the robot is supposed to be moving to. This will allow us to see the robot moving with respect to other objects on the screen. Notice the negative Y component to their position. This puts the objects under where the robot is moving to, and he will stand on top of them when he gets to the right spot.


Finally, we want to set the camera to a good viewing point to see this from. We will move the camera to get a better position:


Now compile and run the code. You should see something like this:


Before continuing to the next section, make note of the constructor of MoveDemoClass. We are passing in myRoot, myNode, and myRobot.


We are now going to setup some basic animation. Animation in Ogre is very simple. To do this, you need to get the AnimationState from the Entity object, set its options, and enable it. This will make the animation active, but you will also need to add time to it after each frame in order for the animation to run. We'll take this one step at a time. First, go to the MoveDemoClass constructor (the New Subroutine) and add the following code:


The second line gets the AnimationState out of the entity. In the third line we call setLoop( true ), which makes the animation loop over and over. For some animations (like the death animation), we would want to set this to false instead. The fourth line actually enables the Animation. But wait...where did we get “Idle” from? How did this magic constant slip in there? Every mesh has their own set of Animations defined for them. In order to see all of the Animations for the particular mesh you are working on, you need to download the OgreMeshViewer and view the mesh from there.

Now, if we compile and run the demo we see...nothing has changed. This is because we need to update the animation state with a time every frame. Find the AnimationFrame function, and add this line of code at the beginning of the function:


And of course we need to add an event handler to call AnimationFrame. We will do this in the MoveDemoClass constructor so that it is scalable.


Now build and run the application. You should see a robot performing his idle animation standing in place.

Did you notice that we actually have TWO FrameEvents? One calls FrameStarted which handles most of the input & camera repositioning. The second one is AnimationFrame which is part of the MoveDemoClass. It theory we could create 100 MoveDemoClass instances and we would have 100 associated FrameEvent listeners.

Moving the Robot

Now we are going to perform the tricky task of making the robot walk from point to point. Before we begin I would like to describe the variables that we are storing in the MoveDemoListener class. We are going to use 4 variables to accomplish the task of moving the robot. First of all, we are going to store the direction the robot is moving in myDirection. We will store the current destination the Robot is traveling to in myDestination. We will store the distance the robot has left to travel in myDistance. Finally, we will store the robot's moving speed in myWalkSpeed.

Let's set up the MoveDemoClass variables. We'll set the walk speed to 35 units per second. There is one big thing to note here. We are explicitly setting mDirection to be the ZERO vector because later we will use this to determine if we are moving the Robot or not.


Now that this is done, we need to set the robot in motion. To make the robot move, we simply tell it to change animations. However, we only want to start the robot moving if there is another location to move to. For this reason we call the nextLocation function. Add this code to the top of the AnimationFrame Function just after the AnimationState::addTime call:


If you compile and run the code right now, the robot will walk in place. This is because the robot starts out with a direction of ZERO and our NextLocation function always returns true. In later steps we will be adding a bit more intelligence to the NextLocation function.

Now we are going to actually move the robot in the scene. To do this we need to have him move a small bit every frame. Go to the AnimationFrame Function. Replace the previous code with the following:


Now, we need to check and see if we are going to “overshoot” the target position. That is, if myDistance is now less than zero, we need to “jump” to the point and set up the move to the next point. Note that we are setting myDirection to the ZERO vector. If the NextLocation function does not change myDirection (IE there is nowhere left to go) then we no longer have to move around.


Now that we have moved to the point, we need to setup the motion to the next point. Once we know if we need to move to another point or not, we can set the appropriate animation; walking if there is another point to go to and idle if there are no more destination points. This is a simple matter of setting the Idle animation if there are no more locations.


This takes care of when we are very close to the target position. Now we need to handle the normal case, when we are just on the way to the position but we're not there yet. To do that we will translate the robot in the direction we are traveling, and move it by the amount specified by the move variable. This is accomplished by adding the following code:


We are almost done. Our code now does everything except set up the variables required for movement. If we can properly set the movement variables our Robot will move like he is supposed to. Find the NextLocation function. This function returns false when we run out of points to go to. This will be the first line of our function. (Note you should leave the return true statement at the bottom of the function.)


Now we need to set the variables. First we will pull the destination vector from the WalkList Queue. We will set the direction vector by subtracting the SceneNode's current position from the destination. We have a problem though. Remember how we multiplied myDirection by the move amount in AnimateFrame? If we do this, we need the direction vector to be a unit vector (that is, it's length equals one). The normalise function does this for us, and returns the old length of the vector. Handy that, since we need to also set the distance to the destination.


Now compile and run the code. It works! Sorta. The robot now walks to all the points, but he is always facing the Vector3.UNIT_X direction (his default). We will need to change the direction he is facing when he is moving towards points.

What we need to do is get the direction the Robot is facing, and use rotate function to rotate the object in the right position. The first line gets the direction the Robot is facing. The second line builds a Quaternion representing the rotation from the current direction to the destination direction. The third line actually rotates the Robot.


Basically speaking, Quaternions are representations of rotations in 3 dimensional space. They are used to keep track of how the object is positioned in space, and may be used to rotate objects in Ogre. In the first line we call the getOrientation method, which returns a Quaternion representing the way the Robot is oriented in space. Since Ogre has no idea which side of the Robot is the "front" of the robot, we must multiply this orientation by the UNIT_X vector (which is the direction the robot "naturally" faces) to we obtain the direction the robot is currently facing. We store this direction in the src variable. In the second line, the getRotationTo method gives us a Quaternion that represents the rotation from the direction the Robot is facing to the direction we want him to be facing. In the third line, we rotate the node so that it faces the new orientation.

There is only one problem with the code we have created. There is a special case where SceneNode.rotate will fail. If we are trying to turn the robot 180 degrees, the rotate code will bomb with a divide by zero error. In order to fix that, we will test to see if we are performing a 180 degree rotation. If so, we will simply yaw the robot by 180 degrees instead of using rotate. To do this, replace the lines we just put in with this:


All of this should now be self explanatory except for what is wrapped in that if statement. If two unit vectors oppose each other (that is, the angle between them is 180 degrees), then their dot product will be -1. So, if we dotProduct the two vectors together and the result equals -1.0f, then we need to yaw by 180 degrees, otherwise we use rotate instead. Why do I add 1.0f and check to see if it is less than 0.0001f? Don't forget about floating point rounding error. You should never directly compare two floating point numbers. Finally, note that in this case the dot product of these two vectors will fall in the range -1, 1. In case it is not abundantly clear, you need to know at minimum basic linear algebra to do graphics programming! At the very least you should review the [[Quaternion and Rotation Primer]] and consult a book on basic vector and matrix operations.

Now our code is complete! Compile and run the demo to see the Robot walk the points he was given.

Final Code


Exercises for Further Study

Easy Questions

  1. Add more points to the robot's path. Be sure to also add more knots that sit under his position so you can track where he is supposed to go.
  2. Robots who have outlived their usefulness should not continue existing! When the robot has finished walking, have him perform the death animation instead of idle. The animation for death is “Die”.

Intermediate Questions

  1. There is something wrong with mWalkSpeed. Did you notice this when going through the tutorial? We only set the value once, and never change it. This should be a constant static class variable. Change the variable so that it is.
  2. The code does something very hacky, and that's track whether or not the Robot is walking by looking at the mDirection vector and comparing it to Vector3::ZERO. It would have been better if we instead had a boolean variable called mWalking that kept track of whether or not the robot is moving. Implement this change.

Difficult Questions

  1. One of the limitations of this class is that you cannot add points to the robot's walking path after you have created the object. Fix this problem by implementing a new method which takes in a Vector3 and adds it to the mWalkList deque. (Hint, if the robot has not finished walking you will only need to add the point to the end of the deque. If the robot has finished, you will need to make him start walking again, and call nextLocation to start him walking again.)

Expert Questions

  1. Another major limitation of this class is that it only tracks one object. Reimplement this class so that it can move and animate any number of objects independently of each other. (Hint, you should create another class that contains everything that needs to be known to animate one object completely. Store this in a STL map object so that you can retrieve data later based on a key.) You get bonus points if you can do this without registering any additional frame listeners.
  2. After making the previous change, you might have noticed that Robots can now collide with each other. Fix this by either creating a smart path finding function, or detecting when robots collide and stopping them from passing through each other.

;Proceed to MOgre VB.NET Intermediate Tutorial 2 RaySceneQueries and Basic Mouse Usage