Opengl manual states: When fog is enabled, objects that are farther from the viewpoint begin to fade into the fog color. , but it seems to me, that its not calculated in relation to viewport, but it goes from modelview 0,0,0 and only along Z axis. I like to move my viewport in projection mode, so i dont have to spin the whole scene around.

So, my question is: is there a way that fog is really calculated relative to viewport?

The viewport change doesn’t make any changes to the matrices. It’s used in the last step of the calculations to calculate the final window coordinates.

That being said, if you are doing anything other than glFrustum, glOrtho, gluPerspective, gluOrtho2d in the PROJECTION matrix, you are going to mess up your fog calculations.

Calls like gluLookAt, glTranslate, glRotate, glScale, etc. should be done on the MODELVIEW matrix.

Originally posted by Deiussum:

The viewport change doesn’t make any changes to the matrices

If so, what is the projection matrix stack for, nothing? I dont think so. Moving viewport in projection mode works just fine, the only problem I ever encountered was fog.

Still waiting for solutions, anyone?

Originally posted by Deiussum:

The viewport change doesn’t make any changes to the matrices

If so, what is the projection matrix stack for, nothing? I dont think so. Moving viewport in projection mode works just fine, the only problem I ever encountered was fog.

Still waiting for solutions, anyone?

I agree with Deiussum. glViewPort is used to specify the rectangle of the window to be used for drawing by GL.

I just tried that changing glViewport with offsets in both projection and modelview and it did maintain the viewport where it was.

void changeproj()

{

glMatrixMode(GL_PROJECTION);

glViewport(0 + projx, 0 + projy, (GLsizei) x_size, (GLsizei) y_size);

glMatrixMode(GL_MODELVIEW);

}

Just used keystrokes to modify projx and projy.

I actually expected the viewport to move around the window, which did not happen. However doing so it was basically like moving left or right or up or down which I think would be better handled by using gluLookAt and modifying the eye and center coordinates which should maintain the fog and allow you to “strafe” left and right and up and down. Or, by translation.

edit…

I probably should have pushed and popped the projection matrix for my test. Should prove if it affects the matrix. Okay I just did it.

void changeproj()

{

glMatrixMode(GL_PROJECTION);

glPushMatrix();

glViewport(0 + projx, 0 + projy, (GLsizei) x_size, (GLsizei) y_size);

glPopMatrix();

glMatrixMode(GL_MODELVIEW);

}

If glViewPort had any effect on the matrix, using this code would have had 0 effect. However, the movement did occur, so glViewport has no effect on matrix.

Try gluLookAt for your purposes. You could easily offset it (using vectors) and it will affect the matrix. Though, like Deissium said, better used in modelview matrix, though I have no experience with it as I leave it at default.

Another edit…

It does state in the blue book that glViewport specifies the affine transformation of x and y from normalized device coordinates to window coordinates. If any matrix is actually being affected it is not the projection or modelview matrices.

Sorry, I probably edited this thing 3 or 4 times. Anyway, because it does not have any effect on the matrix, that is the reason your fog is not behaving as you expect it to.

[This message has been edited by shinpaughp (edited 02-27-2003).]

[This message has been edited by shinpaughp (edited 02-27-2003).]

Please forgive me, I was VERY unprecise. of course vievport change doesnt affect anything, I dont even touch that, i set it once on Init or Resize. What I REALLY ment was VIEWPOINT.

I like to move VIEWPOINT this way:

Drawscene function:

…

glMatrixMode(GL_PROJECTION);

glLoadIdentity();

gluPerspective(…);

…

glRotatef(…);

glTranslatef(…);

…

glMatrixMode(GL_MODELVIEW);

glLoadIdentity();

…etc

So, the more precise question is: how do i tie fog start, end &direction to PROJECTION coords, not MODELVIEW?

Ohno. NEVER rotate the projection matrix… thats nearly allways a very bad idea.

put the rotation and translation of the ‘camera’ as the first matrices in the modelview instead… the code shouldt matter that much, but all the lighing and fog calulations are done between the matrices so you will screw up both light and fog, and most probably generated texturecoords by trying to rotate the projection matrix.

Originally posted by Mazy:

Ohno. NEVER rotate the projection matrix… thats nearly allways a very bad idea.

You know what? I dont believe you. I,ve put this method to work with lighting & texCoords before. Works just fine. And just found out what was wrong with fog (a simple bug). You know, projection matrix is there to use it. But if you prefer to do some complex whole scene modelview acrobacy, or use the god forsaken gluLookAt(), well…

the projection matrix is there to do the projection, ie 3d to 2d transform… nothing else.

added:

http://openglforums.com/tutorials/tutorial6.html

quote from the text :

The projection matrix is used for the projection transformation. This means that it’s used to set up the shape of the viewing volume and nothing else!. You might get away with using it for the viewing transformation, but if you do you almost certainly will get problems with fog, z-buffer etc. Another thing you can do is define a custom projection matrix (with glLoadMatrix() etc.). If you want to do this, make sure you know what you’re doing and that you really need to it. I’ve never had to do this.

[This message has been edited by Mazy (edited 02-27-2003).]

Originally posted by W. C. Picker:

[b] If so, what is the projection matrix stack for, nothing? I dont think so. Moving viewport in projection mode works just fine, the only problem I ever encountered was fog.

Still waiting for solutions, anyone?

[/b]

Well… if you don’t believe me, you don’t need to take my word for it. The exact calculations can be found in the OpenGL specifications. The only place the viewport comes in is in the last step of the calculations after the vertex has been multiplied by both the MODELVIEW and PROJECTION matrices.

As I stated in my previous post you should only use methods like glFrustum, glOrtho, gluPerspective, and gluOrtho2D on the PROJECTION matrix. Think of the PROJECTION matrix as determining the properties of the lens you place on the camera. The properties of the lens don’t include it’s position. Only things like the FOV, field of depth, etc.

The actual placement should be done on the MODELVIEW matrix, which is where the VIEW part of MODELVIEW comes in. Fog and light and a few other things base their calculations off of the MODELVIEW matrix, so if you’ve placed camera movement in the PROJECTION matrix, it won’t get taken into account.

Originally posted by Mazy:

the projection matrix is there to do the projection, ie 3d to 2d transform… nothing else.

Okay, okay man, i didnt mean to be rude. If you dont want to mess around with projection matrix - you dont have to (however, you choose the hard way).

But now goes the fun part, please sit comfortably: you can draw geometry, position lights etc. while in projection mode (yep.).And one more thing about it: its damn useful!

I mean i do KNOW it cause i made a few progs using projection matrix transformations.

One advice, dont waste your time reading crappy tutorials written by uhm… Vic? If you believe the written word so much, i got one from OpenGL programming guide:

The frustum has a default orientation in three-dimensional space. You can perform rotations or translations on the projection matrix to alter this orientation, but this is tricky and nearly always avoidable.

not the same, is it? So you can set up the shape of the volume and SOMETHING else

The problem is, I dont find that tricky, so theres no reason to avoid it.

However, i dont recommend scaling in projection mode

cheers,

[This message has been edited by W. C. Picker (edited 02-27-2003).]

Im not just messing with you, im trying to help. you will see alot of strange light artifacts ( the light arent at the choosed position, or a spotlight arent pointing the right way) sooner or later if you have transformations in the projection matrix… its not only that tutorial, i have my own experice of it, and its mentioned in the red book as well ( a very accepted book in the opengl community ), but if it works fine for you, then by all means continue with it…

Glad I was wrong about what you were doing. I was wondering why anyone would want to change the viewport with each frame or whatever. Though it did seem to work well for a strafing effect. But, I think I’ll pass.

WC if you want to put up some code, or provide a link, or email me the code, I would be happy to take a look and let you know what I find. It seems as though it shouldn’t matter which matrix you have transformations in, and yet it could be fog only looks at the modelview matrix and thereby bypasses the translation and rotation you have placed there.

Regardless, good luck.

I just tested it. When performing camera position transformations in modelview everything works great. When I switched it over to projection it worked, but there were nonfogged portion which got worse as I moved around especially farther in the z direction. Best bet, adjust your code as Mazy stated such that projection matrix contains only projection transformations, and modelview contains all translations and rotations. I agree that there shouldn’t be a difference conceptually and mathematically, but the fog calculations may not work as we would expect, perhaps only using the modelview matrix for its calculations or something of the sort. At least try it.

Thanx, Shin for good words.

I managed to deal with that myself That was just little tiny stupid bug.

I’ll shortly describe what my drawscene function actually did:

-First I set up perspective & applied perspective transformations, according to input readings.

-Then I went to modelview and drew my whole beautiffuly fixed never moving scene.

-After that i went to perspective again (I’m a messy programmer, aint I? ) set up Ortho2D and drew headsup display. but first i had to LoadIdentity, so then i was left with different perspective matrix than was used to draw scene! That’s why i had a fixed fog!

Thats all, that simple.

A pair of push/popmatrix did the trick.

A seed of projection transforming has been planted, or something…

Best wishes,

shinpaughp said:

I agree that there shouldn’t be a difference conceptually and mathematically, but the fog calculations may not work as we would expect, perhaps only using the modelview matrix for its calculations or something of the sort.

I think that’s what I said when I posted the following…

Fog and light and a few other things base their calculations off of the MODELVIEW matrix, so if you’ve placed camera movement in the PROJECTION matrix, it won’t get taken into account.

To be more specific, if you look at section 3.10 of the OpenGL 1.4 specification, it clearly states that the eye-coordinates are used in the fog calculations. Although it allows for the implementation to make an estimate of the eye-coordinates, in section 2.10, it calculates eye-coordinates by multiplying the object coordinates to the MODELVIEW matrix. It uses the PROJECTION matrix to get the clip coordinates. The viewport is then used to convert the clip coordinates to normalized device coordinates.

Ok. I’ll stop my rambling now.

[This message has been edited by Deiussum (edited 02-27-2003).]

Thanks Deiussum for explaining it. I thought I had read it somewhere…