Creating a simple first-person camera system         Quake 3 Arena style camera

Original version by xplozyph.


If, like me, you want to use some kind of first-person camera in the Quake 3 Arena style, thus a free-look camera with a pitch limited between -90 degrees and 90 degrees, you are at the right page!

To make it relatively simple and powerful, we are going to use multiple SceneNodes. Do not be afraid if you have never used them, it is a really simple concept, at least, for what we are going to use them.

Warning: This is outdated as it uses an old version of ExampleFrameListener. The new ExampleFrameListener uses OIS input such as mKeyboard->isKeyDown() and doesn't use any SceneNodes, but the camera can easily be attached to a Character's SceneNode to achieve the same effect as this document aims to do.

Basic understanding of the SceneNode concept

A SceneNode is just some kind of special spatial "container". It can "contain" just other SceneNode as well as Entity, Camera and other inheritent of SceneNode and MovableObject classes (and their own inheritent as well).

Why should we worry about them? Because each SceneNode has its own space transformations. Space transformations are scale, rotation (orientation) and translation (position). But what is still more interesting it is that they also inherit their parent's space transformations.

A small example being worth a thousand words: we have SceneNode B which inherits SceneNode A. Then, we apply a rotation of 90 degrees around SceneNode A's Y-axis. Now, if we read the SceneNode B's Y-axis orientation angle (we are going to see how to do that in this particular case), we see it is 90 degrees!

For those ones who would not have understood or realised, if SceneNode B would not inherit from SceneNode A, when we would have read SceneNode B's Y-axis orientation angle, it would have returned 0 degrees (default orientation), despite the fact that SceneNode A's Y-axis orientation angle of 90 degrees.

Note that this is also true for inheritent of MovableObject (Entity, Camera, etc...).

It is that SceneNode-SceneNode and SceneNode-MovableObject space transformation inheritage property we are going to use to build up our customised first-person camera.

So, let's go :-)

Details about how to achieve the desired effect

Here is the layout of our SceneNode hierarchy:

cameraNode (Ogre::SceneNode *)
      cameraYawNode (Ogre::SceneNode *)
     cameraPitchNode (Ogre::SceneNode *)
     cameraRollNode (Ogre::SceneNode *)
           camera (Ogre::Camera *)

cameraNode will be the hierarchy's top SceneNode. It is going to handle camera's position (-+camera+- will inherit its translation space transformation from cameraRollNode which will inherit it from cameraPitchNode, etc...).

As you have probably guessed, cameraYawNode will handle... camera's yaw "orientation", cameraPitchNode will handle camera's pitch "orientation" and, finally, cameraRollNode will handle camera's roll "orientation".

Euler's angles and gimbal lock effect

Each rotation (orientation) space transformation axis angles will be independent of each others. The yaw, pitch and roll will be hermetically separated. This will avoid the gimbal lock effect, inherent to Euler's angles (yaw, pitch and roll) manipulation.

The effect appears as soon as you change the value of one of those three angles, you also ineluctably change the others two. That results in completely disordered orientation and crazy rotation, that is the so-called gimbal lock effect.

What about yaw, pitch and roll?

But you may wonder: "What is the yaw, the pitch and the roll?".

Well, simply put, the yaw is the angle of rotation around the Y-axis, pitch is the one around the X-axis and the roll is the one around the Z-axis.

Dive into the code

First, we declare some new variables in our FrameListener class:

Ogre::SceneNode *cameraNode;
 Ogre::SceneNode *cameraYawNode;
 Ogre::SceneNode *cameraPitchNode;
 Ogre::SceneNode *cameraRollNode;

Then, we jump into the FrameListener's constructor and initialise those fancy new variables the right way with respect to the layout we drew above:

// Create the camera's top node (which will only handle position).
 this->cameraNode = this->sceneManager->getRootSceneNode()->createChildSceneNode();
 this->cameraNode->setPosition(0, 0, 500);
 // Create the camera's yaw node as a child of camera's top node.
 this->cameraYawNode = this->cameraNode->createChildSceneNode();
 // Create the camera's pitch node as a child of camera's yaw node.
 this->cameraPitchNode = this->cameraYawNode->createChildSceneNode();
 // Create the camera's roll node as a child of camera's pitch node
 // and attach the camera to it.
 this->cameraRollNode = this->cameraPitchNode->createChildSceneNode();

The first stone has been dropped.

Note that you should ensure that your camera and camera's yaw, camera's pitch and camera's roll nodes are all located at (0, 0, 0), which is the default location. Ensure not to call this->camera->setPosition(someX, someY, someZ) or this->camera->translate(someOtherX, someOtherY, someOtherZ) anywhere in your program's code (or to cancel its effect by calling this->camera->setPosition(0.0f, 0.0f, 0.0f)). Else you will have undesired camera-rotates-around-a-point effect (it is my experience that is speaking ;-P).

Now, delete all FrameListener's moveCamera() method content (do not remove the method itself, just its content) and replace it by the following:

Ogre::Real pitchAngle;
 Ogre::Real pitchAngleSign;
 // Yaws the camera according to the mouse relative movement.
 // Pitches the camera according to the mouse relative movement.
 // Translates the camera according to the translate vector which is
 // controlled by the keyboard arrows.
 // NOTE: We multiply the mTranslateVector by the cameraPitchNode's
 // orientation quaternion and the cameraYawNode's orientation
 // quaternion to translate the camera accoding to the camera's
 // orientation around the Y-axis and the X-axis.
 this->cameraNode->translate(this->cameraYawNode->getOrientation() *
                             this->cameraPitchNode->getOrientation() *
 // Angle of rotation around the X-axis.
 pitchAngle = (2 * Ogre::Degree(Ogre::Math::ACos(this->cameraPitchNode->getOrientation().w)).valueDegrees());
 // Just to determine the sign of the angle we pick up above, the
 // value itself does not interest us.
 pitchAngleSign = this->cameraPitchNode->getOrientation().x;
 // Limit the pitch between -90 degress and +90 degrees, Quake3-style.
 if (pitchAngle > 90.0f)
     if (pitchAngleSign > 0)
         // Set orientation to 90 degrees on X-axis.
                                                                Ogre::Math::Sqrt(0.5f), 0, 0));
     else if (pitchAngleSign < 0)
         // Sets orientation to -90 degrees on X-axis.
                                                                -Ogre::Math::Sqrt(0.5f), 0, 0));

Then, we replace some proposed default controls and add some others in the FrameListener's processUnbufferedKeyInput() method (I assume you base yourself on the ExampleFrameListener, else you should be able to apply it to your own particular case ;-]):

// Move camera upwards along to world's Y-axis.
     //this->translateVector.y = this->moveScale;
     this->cameraNode->setPosition(this->cameraNode->getPosition() + Ogre::Vector3(0, 5, 0));
 // Move camera downwards along to world's Y-axis.
     //this->translateVector.y = -(this->moveScale);
     this->cameraNode->setPosition(this->cameraNode->getPosition() - Ogre::Vector3(0, 5, 0));
 // Move camera forward.
     this->translateVector.z = -(this->moveScale);
 // Move camera backward.
     this->translateVector.z = this->moveScale;
 // Move camera left.
     this->translateVector.x = -(this->moveScale);
 // Move camera right.
     this->translateVector.x = this->moveScale;
 // Rotate camera left.
 // Rotate camera right.
 // Strip all yaw rotation on the camera.
 // Rotate camera upwards.
 // Rotate camera downwards.
 // Strip all pitch rotation on the camera.
 // Tilt camera on the left.
 // Tilt camera on the right.
 // Strip all tilt applied to the camera.
 // Strip all rotation to the camera.

If you want to see what is your current orientation around each axis, here is a way to proceed: copy the following code into the FrameListener's updateStats() method (in the try { } code block).

this->renderWindow->setDebugText("Camera orientation: (" 
     + ((this->cameraYawNode->getOrientation().y >= 0) ? std::string("+") : 
     std::string("-")) + "" + Ogre::StringConverter::toString(Ogre::Math::Floor(2 * 
     Ogre::Degree(Ogre::Math::ACos(this->cameraYawNode->getOrientation().w)).valueDegrees())) + ", " + 
     ((this->cameraPitchNode->getOrientation().x >= 0) ? std::string("+") : std::string("-")) + "" + 
     Ogre::StringConverter::toString(Ogre::Math::Floor(2 * 
     Ogre::Degree(Ogre::Math::ACos(this->cameraPitchNode->getOrientation().w)).valueDegrees())) + ", " + 
     ((this->camera->getOrientation().z >= 0) ? std::string("+") : std::string("-")) + "" + 
     Ogre::StringConverter::toString(Ogre::Math::Floor(2 * 
     Ogre::Degree(Ogre::Math::ACos(this->camera->getOrientation().w)).valueDegrees())) + ")");

That is it! Now, you should have a working first-person camera :-) Just glance at your code, ensure you have not comitted any mispelling or bad copy/paste or forgot any parts of this tutorial, compile it and enjoy!

Some remarks

Some people may argue: "Why should I bother handling a camera's roll node? I could apply the roll rotation directly to the camera!". Yes, you are right, and it would theoretically change nothing, except you would get rid of an intermediary SceneNode. To be honest, I've even done it in my own code, but let's keep that a secret, otherwise I could get flamed by the purists!

The order of the SceneNodes is important for the FPS camerasystem, so when you connect first the cameraPitchNode and then the cameraYawNode, you will get a complete different transformation. Because Matrix multiplications are not commutative. Remember that and try it yourself.

And of course apply them separately - that is the requirement against the gimbal lock effect. For more information about the quaternions, check out the Quaternion and Rotation Primer article.

Finally, I would say that the same rule as explained in the preceding paragraph applies for the cameraNode translation (for the camera to move into the world according to the keyboard's arrow keys) about the order of the orientation quaternions (you know, the getOrientation() methods). Also, despite my very little knowledge about quaternion and vectors, you should respect the order of multiplication between the translateVector and the orientation quaternions.

Last words, you might wonder why I have not included the cameraRollNode's orientation quaternion in the multiplication given to the cameraNode's translate() method: that is because I do not want the roll rotation of my camera to influence its displacement, it is as simple as that :-)

Note: I may not understand much of the actual working of this, but I've found that modifying a camera node without updating all of the underlying ones will result in a delayed camera update. The solution I set up is to call needUpdate() on all the nodes (recursively) attached to the node I'm updating. E.g.: if you call cameraYawNode->yaw(degree) you should call cameraPitchNode->needUpdate() and cameraRollNode->needUpdate() too. -nyxkn

Alias: Creating_a_simple_first-person_camera_system