PureBasic Forums - English

The move mode. It can be one of the following values:
#PB_Relative: relative move, from the current camera position (default).
#PB_Absolute: absolute move to the specified position.

combined with one of the following values:
#PB_Local : local move.
#PB_Parent: move relative to the parent position.
#PB_World : move relative to the world.

Henry00 wrote: but the rotation is a PureBasic problem...?

The problem is that there are multiple combinations of pitch/yaw/roll which result in the same quaternion.
When you try to convert a quaternion to euler, the algorithm has no way of knowing which combination of values you wanted from the many valid possibilities.

For example, think of a spaceship facing forwards. Now pitch the ship 180 degrees. It is now upside down facing backwards.
Now think of a second spaceship facing forwards. Don't pitch it, instead yaw it 180 degrees and roll it 90 degrees. It's now upside down facing backwards.
Two different combinations of euler angles, with the same end result. Both would generate the quaternion <0,1,0,0> (off the top of my very tired head).
The quaternion doesn't care how the spaceship got to being upside down and backwards, it just knows that's how it's facing, and that's all it stores.
When converting back to euler from the quaternion, which result should it tell you: P=180,Y=0,R=0 or P=0,Y=180,R=90?

The moral of the story is: going from a quaternion to a euler combination will always give a correct result, but maybe not the one you wanted. If you want consistant eulers, you need to store them as eulers.

Q. Why do the tutorials and people on the forum suggest using two scene nodes to attach my camera to?

A. The recommendation is to create a scene node, say "CamNode" and a pitch node, say "PitchNode". "PitchNode" is attached to "CamNode" and the camera is attached to "PitchNode". Movement and Yaw are applied to the CamNode. Pitch is applied to the "PitchNode", only. The reason for this is because one can generate roll through euler angles of pitch and yaw. Often one uses the mouse to control the camera look angle. One expects to move the mouse up to look up, right to look right, down to look down. However this is the same as pitch up, yaw right and pitch down. Try this with a desk object. That sequence induces roll. Using two separate nodes gives you the equivalent of a flat disk that floats around. Attached to the bottom of that disk is a camera that can look only up or down. By rotating the disk and moving the camera up or down you can view any angle. Yaw on the disk affects the camera, but pitch on the camera does not affect the disk. This provides the effect that most people expect.

Alternate A. For a simple Free Camera you can use the one node and just rotate in the appropriate coordinate space. Once you want to start mixing "roll" into this, you should go back to completely local space rotations---at which point you're probably not trying to make a simple Free Camera for debug purposes.

Code: Select all

node->pitch( mPitch, Node::TS_LOCAL );
 node->yaw( mYaw, Node::TS_WORLD );
 node->translate( mTranslate, Node::TS_LOCAL );

The effect of this is to pitch the scenenode relative to itself, but to yaw the scenenode relative to the world. This means yaw is always horizontal and no roll is induced by the two rotations. The translate call ensures you are always moving along the SceneNode's z axis. i.e., the direction it is facing.

Olby wrote: In PB+OGRE I still can't get it just right. My camera spins out of control and does all sorts of other unexpected behaviour. Rotation method should be revised or at least supply us with a good documentation on this.