next »

[Mikademus]

In my set-up I have a camera that must be able to handle both free-look swivelling and orbiting modes. Since I am using OGRE the internal Camera class is attached to a scene node, or rather, it is contingent on four chained scene nodes, one for position, yaw, pitch, and roll. The camera is attached to the last one (roll).

Code:

In a class "Camera":
        if (!pCameraNode_) pCameraNode_ = pSceneManager->createSceneNode( pos_name + "/position" );
        if (!pYawNode_)    pYawNode_    = pCameraNode_->createChildSceneNode( pos_name + "/yaw" );
        if (!pPitchNode_)  pPitchNode_  = pYawNode_->createChildSceneNode( pos_name + "/pitch" );
        if (!pRollNode_)   pRollNode_   = pPitchNode_->createChildSceneNode( pos_name + "/roll" );
        if (!pOgreCamera_) pOgreCamera_ = pSceneManager->createCamera( cam_name );

        pOgreViewport_ = pWindow->addViewport( pOgreCamera_, z_order, left, top, right, bottom );

        pOgreCamera_->setNearClipDistance( 5.0f ); 
        pOgreCamera_->setFarClipDistance( 20000.0f ); 
        pOgreCamera_->setAspectRatio( Ogre::Real(pOgreViewport_->getActualWidth()) / Ogre::Real(pOgreViewport_->getActualHeight()) );

        pRollNode_->attachObject( pOgreCamera_ );

My problem is that my maths skilz are definitely non-l33t and I don't really know how to orient these nodes to look at at given position. I most certainly must orient the yaw and pitch (let's ignore the roll, unless it is trivial) separately, but how do I calculate this?

[muku]

I got the math down, but I don't know what these nodes are. So if you describe in a bit more detail what they do, I'm sure I can help you.

[Rob Lach]

IIRC, The ogre camera class has a "lookat" function which automatically sets the orientation quaternion. Before you call that just transpose it to wherever your camera system expects it to be and then call lookat and pass in the coordinates of where you want to look.

It'd help if you further explained what you're trying to do since I don't really understand why you're adding nodes for yaw/pitch/roll, and if you need to do it that why, why you aren't specifying any distance or position nodes.

Just to clarify, by Free-look swiveling do you mean arcball? Also, An orbit camera is a fairly complex camera that takes into account previous aspects, ie google earth. I'm interpreting "orbiting modes" as an animated arcball camera but I may be incorrect.

[Mikademus]

Pierog, it has indeed. However, it is generally better practice to not orient the camera itself, but rather to attach it to a scene node. The reason for the separation of into individual nodes for position, yaw, pitch and roll is to avoid gimbal lock and simplify camera management. For instance when the camera rotates left or right with the mouse, only the yaw node is affected. With "freelook" I mean a vanilla FPS camera.

Muku, the nodes are scene nodes in the OGRE scene graph. Basically they are a world matrix (actually a quaternion) describing a position and orientation, and they can be hierarchically linked to each other.

So I have these scene nodes:

Code:

Position <-- Yaw <-- Pitch <-- Roll 

                                ^
              The Ogre::Camera is attached here

[BorisTheBrave]

If each node has position and orientation, isn't one node sufficent for the camera? I'm particularly confused as you describe the cameras orientation in terms of yaw, pitch and roll, which is 3 angles - you can get gimbal lock from that, so you just seem to have made things worse.

[Rob Lach]

Pierog, it has indeed. However, it is generally better practice to not orient the camera itself, but rather to attach it to a scene node. The reason for the separation of into individual nodes for position, yaw, pitch and roll is to avoid gimbal lock and simplify camera management. For instance when the camera rotates left or right with the mouse, only the yaw node is affected. With "freelook" I mean a vanilla FPS camera.

I think you're overthinking things. I agree it's better to attach it to a scene node, but the position/orientation properties of the node should be sufficient. You can avoid gimbal lock by sticking to quaternions. Actually, by putting it into a yaw/pitch/roll system, you are setting yourself up for actually creating a perfect example of gimbal lock.



As for the ease of use, I don't think you'll be gaining much from the axis separation. You're more likely to be complicating things. Consider that you can replicate the action you described very easily just by using the dx of the mouse as the magnitude of a quaternion rotation about the y axis.

[Mikademus]

Pierog, you might indeed be correct. Which would be frustrating, because when asking for assistance in the OGRE forums they point to the article I linked to. Perhaps not the perfect catch 22, but close enough.

So let's ignore the code and architectural details and let me rephrase the question instead: I need the yaw and pitch angles between two 3D points.

[muku]

So let's ignore the code and architectural details and let me rephrase the question instead: I need the yaw and pitch angles between two 3D points.

• For yaw, ignore the 'height' component of the positions (in other words, project them to a 2-dimensional plane) and then use the formula for the angle between two 2D vectors
• For pitch, you can either use asin(h / distance) or atan(h / 2ddist), where h is the height difference between the points, distance is their 3D distance, and 2ddist is their distance in the 2D plane you projected onto in the first step (i.e. disregarding height component).

Still I'm a bit confused why you'd want to use Euler angles for this... quaternions should handle this perfectly fine.

[Pishtaco]

In my set-up I have a camera that must be able to handle both free-look swivelling and orbiting modes.

If I understand swiveling and orbiting right, then I don't see where gimbal lock or quaternions need to come into this. I'm thinking that swiveling is rotating around a vertical axis and then looking up or down, and orbiting is the same thing, but you also move so that the target is always a fixed distance in front of you. You don't have to do any rolling, and the up-vector of the camera is fixed in the plane made by the direction you are looking and the world's vertical axis. Google suggests that Ogre will keep the camera up-vector like this automatically, so all you need to do is set the position of the camera and the direction you want it to face.

This is basically what I have in my game (except I set the up-vector myself), so I'll describe that.

For the swiveling camera, the parameters for the camera are a vector p for your position, an azimuth angle for the compass direction you are facing, and an elevation angle. From the azimuth and elevation with a little trigonometry you can get a unit vector v for the direction you want to look in. Then you set the position of the camera to be p and the direction to be v - it looks like the Ogre camera has commands for both of these. You set the mouse directly to change the azimuth or elavation.

For the orbiting camera, it's almost exactly the same, except that if the target is at position t and you want to orbit at distance d from it, you set the camera position to be t-d*v and the direction again as v. Mouse controls are just the same.

Sorry if I've misunderstood what the question is about.