Thread: Rendering models in different orientations

Hi everyone,
I have run into a huge brick wall. I am writing a true-3d space flight simulator in OpenGL. Each object in the world will have an orientation defined by a direction vector and an up vector. Each object also has a position vector.

Here is what I thought was the easiest way to render a model. gluLookat seemed extremely appropriate for what I wanted to do. (Does this make sense?)

Code:

void GraphicsEntity::render() const{
    glPushMatrix();
    
        glTranslatef(pos.getx(), pos.gety(), pos.getz());
        gluLookAt(0, 0, 0, dirVec.getx(), dirVec.gety(), dirVec.getz(), upVec.getx(), upVec.gety(), upVec.getz());
        
        glCallList(model->getDisplayList());
        
    glPopMatrix();
}

I have written methods for the Entity class which pitch the object up and down and yaw left and right, changing the direction and up vectors appropriately (I have checked and they are being changed correctly). The entity class also has a 'right vector'.

The problem is that when I pitch a ship up or down in the game, it always only rotates around the ship around the world x axis and in the case of yawing left or right it always rotates around the world y axis, when it SHOULD rotate around the right vector and up vector of the object respectively. The idea being that no matter what rotations you have already done the yaw will still turn the ship left or right from the ship's perspective.

Here are some screenshots of what I have so far:
Before any rotations
After pitching up
Yawing after pitching

Any help would be appreciated, and more clarification on any aspect can be given.

Thank you scwizzo, but I believe that's what I'm doing already. Here's how I calculate the direction and up vectors:

Code:

// Pitchs (rotates) the direction and up vectors 'd' degrees around the right vector
void Entity::pitch(float d){
    vecRotate(dirVec, d, rightVec);
    Vector3d::cross(rightVec, dirVec, upVec);
}

// Yaws (rotates) the right and direction vectors 'd' degrees around the up vector
void Entity::yaw(float d){
    vecRotate(dirVec, d, upVec);
    Vector3d::cross(dirVec, upVec, rightVec);
}

So a pitch always rotates the direction vector around the right vector and then does a cross product to update the up vector.

The vecRotate function is complicated and is based on the equations from here, and I am quite certain it is working correctly as I have check what vectors are getting outputted after each pitch/yaw. So the vectors being represented in the object are correct but the rendering process is somehow wrong. Here is my glut display function:

Code:

//GLUT displays the scene with this function
void display(){
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
    
    glPushMatrix();
    glEnable(GL_TEXTURE_2D);
    
    drawBackground();
    
    glTranslatef(a, b, x);
    
    ge.render();

    glDisable(GL_TEXTURE_2D);

    glPopMatrix();
    
    glutSwapBuffers();
}

Where 'ge' is a global Entity variable that I'm testing with.

Perhaps I am misunderstanding what gluLookAt does?

You are running into gimbal lock where one rotation about an axis causes a rotation about another axis. Another way of saying it is that gimbal lock is when one axis of rotation is mapped either partially or fully onto another axis of rotation.

Solutions to this are to use axis-angle orientations or quaternions.

Rotations for airplanes and spacecraft
Yaw is a rotation about the up vector.
Pitch is a rotation about the right vector.
Roll is a rotation about the look vector.

For spacecraft and airplanes the up vector does not always line up with world up. So if you take an airplace and pitch 90 degrees up and yaw the craft should yaw back and forth as it normally does in any other orientation. If you are not using axis-angle or quaternion rotations the yaw will actually map onto the look vector and the aircraft will roll instead of yaw.

PROBLEM SOLVED.

Everything was working fine and my method of representing orientations with vectors was fine. The problem was, as I suspected, gluLookAt not doing what I thought it should do. Instead I looked up change of basis in my old maths textbooks and realized that changing basis from world co-ordinates to the ships co-ordinates can be done like this:

Code:

void GraphicsEntity::render() const{
    glPushMatrix();
    
        glTranslatef(pos.getx(), pos.gety(), pos.getz());
        
        GLfloat basisChange[16] = {rightVec.getx(), rightVec.gety(), rightVec.getz(), 0, 
                                   upVec.getx(), upVec.gety(), upVec.getz(), 0, 
                                   -dirVec.getx(), -dirVec.gety(), -dirVec.getz(), 
                                   0, 0, 0, 0, 1};
        glMultMatrixf(basisChange);
        
        glCallList(model->getDisplayList());
        
    glPopMatrix();
}

This is easy since the basis vectors for the ship are exactly the orientation vectors I had been using to represent orientation. I cannot explain why gluLookAt behaved the way it did, but this solution works, as a pitch or yaw will rotate the ship around the ships axes now.

Ship before any rotations
After pitching up
And then yawing anti-clockwise works correctly

In case anyone was interested.

Why are you using a look at matrix to orient your objects?

Not sure what you mean. If you're referring to gluLookAt, even though it was designed for setting up the camera, I thought it would still work for facing objects in the correct orientation.

It does provided they have a target to look at. But orienting objects is not always about what they are looking at. Most of the time you orient an object via it's up, look, and right vectors. The only time you would need look at functionality is if you want your object to face another .

Fair enough.

It is strange that no book or articles I have read mention a technique like mine (where you use three basis vectors for each object orientation), they only ever list Euler angles, axis angle, and quaternions. Is this because it is inefficient in some way?

It's probably because it's generally on the first or second page of the chapter -- it's true for any linear transformation, not just a rotation, that the columns of the transformation matrix are the change-of-basis vectors. (Granted, I don't have all that many game math books on my shelf, but they all get there pretty quick, and well before talking about rotations.)