[Plib-users] ssg camera woes / tranformation/coordsystem confusion

[Jakob G. <pi...@st...>]

 Hi. I have some pre-SSG/own code, I'm trying to migrate to SSG.
However, my camera code screws up; it's as if the axes are switched, or
worse.

For example, my code has a direction/rotation matrix, that indicates
the users' rotation around the y axis (it could be a rotation angle instead,
but I'm exploiting that it's a matrix).

However, when I multiply this matrix onto the ssg camera, it rotates around
the _Z_ axis instead!
  Similar problems happen with other parts of the transform (which I've
commented out to dissect the problem).

I wonder if it's a left/righthand coordsys screwup, or maybe that I get the
perspective configured wrongly...

Here snippets from the code that I hope include enough info to illustrate
what I'm doing:

// this updates the direction rotate-matrix that at least has worked OK
"until SSG":
...
      case GLUT_KEY_LEFT:  direction.Rotate(-rotateStep, 0,1,0); break;
      case GLUT_KEY_RIGHT: direction.Rotate( rotateStep, 0,1,0); break;
...

// this how I try to apply my camera for SSG:

  virtual void cameraForSSG(sgMat4& mat) {
    sgMakeIdentMat4(mat);
    sgPostMultMat4(mat, direction.a);
    ... (+ more similar code currently commented out to isolate the problem.
  }



And finally, the render code context it's called from.
Note that this first does non-SSG render, but that... shouldn't be a
problem, as far as I understand?
(the whole point of the exercise is to gradually move all the non-ssg code
to ssg... So
I like to let the non-ssg code do its thing until I know a given part works
well with ssg).

  virtual void renderHandler() { // draw/callback function.
    glClear(GL_COLOR_BUFFER_BIT   | GL_DEPTH_BUFFER_BIT);
    // reset modelview matrix
    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
    nav->renderSetCamera();
    data.world.RenderMe();

    // now render ssg
    glLoadIdentity(); // not really necessary, but not dangerous either?
    sgMat4 cameraMat;
    nav->cameraForSSG(cameraMat);
    ssgSetCamera(cameraMat);
    ssgCullAndDraw(my_ssgScene);  // and here/now it's all wrong...

    glutSwapBuffers();  // necessary change for double buffer mode.
}




One of the things I wondered might be a problem, could be that maybe I don't
succeed in configuring
the non-ssg frustrum and the ssg frustrum the same way.
   The non-ssg frustrum I set with gluPerspective().
The ssg frustrum I set this way:

class FrustumArgs {
public:
  GLfloat top,bottom,left,right,znear,zfar;

  FrustumArgs() {
    top=bottom=left=right=znear=zfar= 0.0;
  }

  void calcFromPerspective(
    GLfloat vFovDeg, // 60.0f, // vertical fov
    GLfloat aspectRatio,
    GLfloat near_, //0.2, // 1.0,  // near clipping plane
    GLfloat far_ //400.0 // far clipping plane
  ) {
    // JG: I call them 'z' because near/far seems to be C++ keywords...
    znear = near_;
    zfar = far_;

    GLfloat vFovRad = vFovDeg * SG_DEGREES_TO_RADIANS; //SG_PI/360.0;

    // from openGL faq: based on fact that
    // vFov*0.5 == atan( (top-bottom)*0.5 / near)
    top = tan(vFovRad*0.5)*znear;
    bottom = -top;
    left  = bottom * aspectRatio;
    right = top * aspectRatio;
  }

};




And then I use it like this:
   ...
    gluPerspective(
      60.0f, // vertical fov
      fAspect,
      0.2, // 1.0,  // near clipping plane
      400.0 // far clipping plane
    );

    frustrumArgs.calcFromPerspective(
      60.0f, // vertical fov
      fAspect,
      0.2, // 1.0,  // near clipping plane
      400.0 // far clipping plane
    );

    ssgSetFrustum(
      frustrumArgs.left,  // JG: I now know that
      frustrumArgs.right, // left/r/b/t is the size of the 'rectangle' at
distance znear!
      frustrumArgs.bottom,
      frustrumArgs.top,
      frustrumArgs.znear,
      frustrumArgs.zfar
    );
   ....

Actually, I don't think this part is the problem,
because I think the ssg frustrum "wins" - the gluPerspective is only set
once,
so after a certain point only the ssg frustrum gets set, again and again (at
least I assume);
so the ssg frustrum is used for all (and the camera stuff still works OK
for all the non-ssg stuff rendered at the same time).


Cheers, and grateful for any help/suggestions/comments offered,
Jakob Gaardsted.