Hi, I have a reshape() function that sets up
a screen via glFrustum(), then after I do
that I setup my camera via gluLookAt() function. Is it a correct way of doing it?
Should I do my camera setup in reshape()?
you need to make sure your gluLookAt() call is when you are in MODELVIEW mode. if you are changing the MODELVIEW matrix each frame, then you need to call gluLookAt() before you draw your geometry (i think)
b
If the values I give gluLookAt could change, I’ll use it ever frame. (Simulating a moving camera for instance.) If I would just be using the same values for gluLookAt ever frame, I put it in my reshape, and then in my display code use a glPushMatrix/glPopMatrix around all the other transformations.
Also, as coredump said, make sure to use it on the MODELVIEW matrix, not the projection matrix. If I’m using gluLookAt in the reshape function it generally looks somehwhat like so…
void reshape(int x, int y)
{
glViewport(0, 0, x, y);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(60.0, (float)x/(float)y, 0.1, 100.0);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
gluLookAt(0.0, 0.0, 10.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0);
}
Note the use of the glLoadIdentity calls above. Those are important so that you don’t continue to multiply to the current projection and modelview matrices.
Originally posted by Deiussum:
[b]If the values I give gluLookAt could change, I’ll use it ever frame. (Simulating a moving camera for instance.) If I would just be using the same values for gluLookAt ever frame, I put it in my reshape, and then in my display code use a glPushMatrix/glPopMatrix around all the other transformations.
Also, as coredump said, make sure to use it on the MODELVIEW matrix, not the projection matrix. If I’m using gluLookAt in the reshape function it generally looks somehwhat like so…
[quote]
void reshape(int x, int y)
{
glViewport(0, 0, x, y);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(60.0, (float)x/(float)y, 0.1, 100.0);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
gluLookAt(0.0, 0.0, 10.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0);
}
Note the use of the glLoadIdentity calls above. Those are important so that you don’t continue to multiply to the current projection and modelview matrices.[/b][/QUOTE]
Why do you use gluPerspective here?
I find it to be a bit more intuitive to use. It basically does the same thing as glFrustum, but lets you specify it in a bit different way.
The reshape function should not include a call to gluLookAt since it doesn’t change the position or orientation of the camera.
Generally, glLoadIdentity and gluLookAt are the first calls in the display function.
One additional thing, beware of a divide by zero when your window is minimised :
[b]
void reshape(int x, int y)
{
glViewport(0, 0, x, y);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(60.0, (float)x/(float)((y==0)?1.0f:y), 0.1, 100.0);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
gluLookAt(0.0, 0.0, 10.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0);
}
[/b]
Originally posted by Jambolo:
[b]The reshape function should not include a call to gluLookAt since it doesn’t change the position or orientation of the camera.
Generally, glLoadIdentity and gluLookAt are the first calls in the display function.[/b]
That’s your opinion. If I’m writing something with a “fixed camera” I really don’t need to use gluLookAt every frame. The reshape or init functions are as good as anyplace else to put gluLookAt in those cases.
Why do you use gluPerspective here?
gluPerspective sets up the PROJECTION matrix. gluLookAt sets up the MODELVIEW matrix. the simple case, you have a sphere at 0,100,0. without gluLookAt, you wouldn’t be able to see the sphere. adding gluLookAt(0,0,0,0,1,0,0,0,1) actually sets the MODELVIEW matrix so all the geometry in your scene gets transformed, and you see the sphere.
b
Originally posted by Deiussum:
[b] If I’m writing something with a “fixed camera” I really don’t need to use gluLookAt every frame. The reshape or init functions are as good as anyplace else to put gluLookAt in those cases.
[/b]
It shouldn’t go in the reshape function because it doesn’t have anything to do with the viewport. Putting it in the display function might slow the frame update by a couple microseconds but that’s a better place to put it.
Jambolo,
I’m not even sure why I’m arguing the semantics about this with you. If I only need to use gluLookAt once, there’s really no need to put it in Display, and many times it doesn’t seem logical to put it there to me. If you don’t like doing that, fine. Don’t. But don’t go saying that it’s wrong to put it elsewhere. It’s all a matter of opinion. I usually put it in my reshape for the simple reason that i’m already doing matrix stuff there, and I often create windows that are not resizeable so it only gets called once.
i agree…and calling it every frame wouldn’t slow the frame rate at all. i’m sure all gluLookAt does is a few calculations, then populates the current matrix.
b
Originally posted by Deiussum:
But don’t go saying that it’s wrong to put it elsewhere. It’s all a matter of opinion.
Fine. It is my opinion that it is wrong to put the gluLookAt call in the reshape function. The original poster was asking if this is where it goes. The answer is no.
You can put it there and it may work, but the reshape function is not the best place to put it. You can also call gluLookAt with the projection matrix and you can call gluPerspective with the modelview matrix. Those will work too, but they are wrong. Anyway, that’s my opinion.
Someone better call the author of the red book and tell them that Jambolo thinks a couple of their examples are wrong. Wouldn’t want all the people who learn from that to go against his opinion. Oh yeah… and Nehe does a glLoadIdentity on the modelview matrix in the example code. According to Jambolo’s logic, it should be wrong to put that there too.
Your example about using gluLookAt in the projection matrix isn’t the same thing. Doing that can mess up stuff like lighting and fog calculations, so that is the wrong thing to do. If you only need gluLookAt once, putting it in the reshape function isn’t going to mess up anything.
Anyway, it’s silly to argue about something so small. This’ll be my last response on the topic.