Camera rotation (cont)

OpenGL Development
#1

Hi, quick question. :slight_smile: I hope the solution is as simple as I imagine. I’ve used the method at the bottom of this page: (http://www.songho.ca/opengl/gl_anglestoaxes.html) to perform rotations on each axis, which works exactly how I want. The problem I’m having with it is with roll rotations (z axis). X and Y work perfectly, but the roll seems to go in the same direction every time, as in left to right and it does so in the same direction regardless of other axis rotations.


    left.x = cy*cz;
    left.y = sx*sy*cz + cx*sz;
    left.z = -cx*sy*cz + sx*sz;

    // determine up axis
    up.x = -cy*sz;
    up.y = -sx*sy*sz + cx*cz;
    up.z = cx*sy*sz + sx*cz;

    // determine forward axis
    "forward.x = sy;
    forward.y = -sx*cy;
    forward.z = cx*cy;"

Here’s where I assume I’m making the error. I noticed the other two axis are determined by adding other axises. Is there something missing from this?

Thanks,
Paul

#2

I can elaborate if my explanation wasn’t clear. :slight_smile:

#3

Please do… I have no idea what you’re asking about… :persecutioncomplex:

#4

Ah, well at the moment I have 3 rotation angles around the x, y and z angles. The block of code above translates the rotation angles into a 3x3 rotation matrix. Everything works as expected, except when rolling on the Z axis (roll).

If I start the app when I’m at the default orientation, then perform a Z axis rotation, it works fine, however if I rotate 90 degrees around the Y axis first (yaw) and then perform the Z axis rotation it appears to perform the Z axis rotation as if the Y axis rotation hadn’t taken place. So after rotating 90 degrees around the Y axis and then performing a Z axis rotation, the camera seems to forward roll.

So basically, any Z axis rotation ignores any other rotation (around X and Y) and just rotates as if it was rotated around the original orientation.
Sorry if that’s a bit long-winded. :slight_smile: Just trying to be descriptive.

#5

Welcome to gimbal lock.

#6

Oh. :frowning: So it’s not a quick solution. I suppose rotation around the z axis isn’t crucial to a 3D camera because with a mouse driven view there’s no way to rotate about it. Would the solution be to not use Euler angles?

#7

In a FPS, you’ll rotate around Y (yaw), then X (pitch) and generally not bother with Z (roll) except maybe as a camera effect not under direct control of the player. Sticking with just those two rotations shouldn’t give you any problems with gimbal lock.

#8

Yeah I can’t imagine many scenarios when I’d require a rotation around the Z axis. That said, would you recommend using another method such as quaternions?

#9

I don’t think quaternions buy you anything in this case. They’re more useful when you need to interpolate the motion from one angle to another, since euler angles are full of singularities like gimbal lock, and quats aren’t.

#10

Personally I think that quaternions are handy for all orientations. The problem is that everyone insists on making them more complicated that is needed. All orientations (in 3d) can be described by an axis and an angle and quaternions represent them in a stable, easy to manipulate and mostly trig free manner. Axis/angle representation is really just an exponential mapping of quaternions BTW.

#11

Well yeah, I’m impartial to the method I use. If I can avoid gimbal lock by using quaternions then I’ll find some resources on them. Before I have a google do you know of any good books or websites that cover them, preferably with a spin on camera orientation?

#12

I don’t know of any accessible description. Really EVERYONE insist on making them more difficult than is needed. I’d suggest looking at a lookAt matrix version first. Basic sketch is you have a lookAt vector (direction the camera is facing) and a world up vector. normalize(lookAt x UP) = right. normalize(right x lookAt) = cameraUp. Shove these into a matrix. Breaks down when camera approaches straight up or down. A quick websearch should yield various implementations. (Something like graham-schmidt … however their names are spelled…will slightly address some computation problems)