Skip to main content
History: Creating a simple first-person camera system
View published page
Source of version: 18
(current)
Original version by ((User:Xplozyph|xplozyph)). {maketoc} !!Introduction 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. ~~#F03:__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 {MONO()}SceneNode{MONO} as well as {MONO()}Entity{MONO}, {MONO()}Camera{MONO} and other inheritent of {MONO()}SceneNode{MONO} and {MONO()}MovableObject{MONO} 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 {MONO()}MovableObject{MONO} ({MONO()}Entity{MONO}, {MONO()}Camera{MONO}, etc...). It is that {MONO()}SceneNode{MONO}-{MONO()}SceneNode{MONO} and {MONO()}SceneNode{MONO}-{MONO()}MovableObject{MONO} 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 {MONO()}SceneNode{MONO} hierarchy: {CODE(wrap="1", colors="c++")} cameraNode (Ogre::SceneNode *) || \/ cameraYawNode (Ogre::SceneNode *) || \/ cameraPitchNode (Ogre::SceneNode *) || \/ cameraRollNode (Ogre::SceneNode *) || \/ camera (Ogre::Camera *) {CODE} -+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: {CODE(wrap="1", colors="c++")} Ogre::SceneNode *cameraNode; Ogre::SceneNode *cameraYawNode; Ogre::SceneNode *cameraPitchNode; Ogre::SceneNode *cameraRollNode; {CODE} 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: {CODE(wrap="1", colors="c++")} // 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(); this->cameraRollNode->attachObject(this->camera); {CODE} 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: {CODE(wrap="1", colors="c++")} Ogre::Real pitchAngle; Ogre::Real pitchAngleSign; // Yaws the camera according to the mouse relative movement. this->cameraYawNode->yaw(this->mRotX); // Pitches the camera according to the mouse relative movement. this->cameraPitchNode->pitch(this->mRotY); // 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() * this->mTranslateVector, Ogre::SceneNode::TS_LOCAL); // 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. this->cameraPitchNode->setOrientation(Ogre::Quaternion(Ogre::Math::Sqrt(0.5f), Ogre::Math::Sqrt(0.5f), 0, 0)); else if (pitchAngleSign < 0) // Sets orientation to -90 degrees on X-axis. this->cameraPitchNode->setOrientation(Ogre::Quaternion(Ogre::Math::Sqrt(0.5f), -Ogre::Math::Sqrt(0.5f), 0, 0)); } {CODE} 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 ;-]): {CODE(wrap="1", colors="c++")} // Move camera upwards along to world's Y-axis. if(inputManager->isKeyDown(Ogre::KC_PGUP)) //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. if(inputManager->isKeyDown(Ogre::KC_PGDOWN)) //this->translateVector.y = -(this->moveScale); this->cameraNode->setPosition(this->cameraNode->getPosition() - Ogre::Vector3(0, 5, 0)); // Move camera forward. if(inputManager->isKeyDown(Ogre::KC_UP)) this->translateVector.z = -(this->moveScale); // Move camera backward. if(inputManager->isKeyDown(Ogre::KC_DOWN)) this->translateVector.z = this->moveScale; // Move camera left. if(inputManager->isKeyDown(Ogre::KC_LEFT)) this->translateVector.x = -(this->moveScale); // Move camera right. if(inputManager->isKeyDown(Ogre::KC_RIGHT)) this->translateVector.x = this->moveScale; // Rotate camera left. if(inputManager->isKeyDown(Ogre::KC_Q)) this->cameraYawNode->yaw(this->rotateScale); // Rotate camera right. if(inputManager->isKeyDown(Ogre::KC_D)) this->cameraYawNode->yaw(-(this->rotateScale)); // Strip all yaw rotation on the camera. if(inputManager->isKeyDown(Ogre::KC_A)) this->cameraYawNode->setOrientation(Ogre::Quaternion::IDENTITY); // Rotate camera upwards. if(inputManager->isKeyDown(Ogre::KC_Z)) this->cameraPitchNode->pitch(this->rotateScale); // Rotate camera downwards. if(inputManager->isKeyDown(Ogre::KC_S)) this->cameraPitchNode->pitch(-(this->rotateScale)); // Strip all pitch rotation on the camera. if(inputManager->isKeyDown(Ogre::KC_E)) this->cameraPitchNode->setOrientation(Ogre::Quaternion::IDENTITY); // Tilt camera on the left. if(inputManager->isKeyDown(Ogre::KC_L)) this->cameraRollNode->roll(-(this->rotateScale)); // Tilt camera on the right. if(inputManager->isKeyDown(Ogre::KC_M)) this->cameraRollNode->roll(this->rotateScale); // Strip all tilt applied to the camera. if(inputManager->isKeyDown(Ogre::KC_P)) this->cameraRollNode->setOrientation(Ogre::Quaternion::IDENTITY); // Strip all rotation to the camera. if(inputManager->isKeyDown(Ogre::KC_O)) { this->cameraYawNode->setOrientation(Ogre::Quaternion::IDENTITY); this->cameraPitchNode->setOrientation(Ogre::Quaternion::IDENTITY); this->cameraRollNode->setOrientation(Ogre::Quaternion::IDENTITY); } {CODE} 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). {CODE(wrap="1", colors="c++")} 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())) + ")"); {CODE} 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 {MONO()}cameraYawNode->yaw(degree){MONO} you should call {MONO()}cameraPitchNode->needUpdate(){MONO} and {MONO()}cameraRollNode->needUpdate(){MONO} too. -nyxkn --- Alias: (alias(Creating_a_simple_first-person_camera_system))
Search by Tags
Search Wiki by Freetags
Latest Changes
Compiled API Reference
Overlay Editor
Introduction - JaJDoo Shader Guide - Basics
RT Shader System
RapidXML Dotscene Loader
One Function Ogre
One Function Ogre
...more
Search
Find
Online Users
257 online users
OGRE Wiki
Support and community documentation for Ogre3D
Ogre Forums
ogre3d.org
Log in
Username
Password
CapsLock is on.
Remember me (for 1 year)
Log in