[Plib-users] ssg camera woes / tranformation/coordsystem confusion
Brought to you by:
sjbaker
|
From: Jakob G. <pi...@st...> - 2006-02-12 09:36:46
|
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.
|