Fog problem
I've got to support a fairly large application, which among other things allows setting a fog.
When I do this in a test example that just renders a few graphic primitives everything works as designed. The fog starts and ends where it is supposed to.
In the larger application however, even though thre is only one pair of calls to lFogf(GL_FOG_START, nearZ); glFogf(GL_FOG_END, farZ);
it produces two fogs. One where it is expected, another one is a mirror reflection of the first one. To the user it looks like the farthest objects are dimmed, the middle objects are bright and the closest ones are dimmed too.
Whatever I do to the code I cannot remove the "front" fog.
Any suggestions ?
It depends on the values of near and far. Try 0.0 to 100.0
[Edited by - V-man on March 10, 2008 10:35:41 PM]
[Edited by - V-man on March 10, 2008 10:35:41 PM]
I tried everything with the same results.
Basically my model spans z values from for example 5 to 40.
If I set the front and rear fog a 5 and 40 everything looks perfect.
Now when I zoom in the size of the model changes. I understand that normally the viewport should change with a static model but in my case the viewport is constant. There are requirements to do exactly that.
So as soon as the front edge of the model crosses z=0 and goes into the negative terrritory that part becomes cued backward. i.e the point close to 0 is bright but the further a point is from z=0 ( closer to the user ) the more of the fog it gets. Combined with the normal fog which is applied at the farther end the whole picure becomes a bit unnatural.
Basically my model spans z values from for example 5 to 40.
If I set the front and rear fog a 5 and 40 everything looks perfect.
Now when I zoom in the size of the model changes. I understand that normally the viewport should change with a static model but in my case the viewport is constant. There are requirements to do exactly that.
So as soon as the front edge of the model crosses z=0 and goes into the negative terrritory that part becomes cued backward. i.e the point close to 0 is bright but the further a point is from z=0 ( closer to the user ) the more of the fog it gets. Combined with the normal fog which is applied at the farther end the whole picure becomes a bit unnatural.
Wait, hold on - am I correct in understanding that you have OpenGL somehow rendering objects that are behind the camera? Or perhaps setting your fog to start at a negative distance from the camera? If so in either case, that might be your problem.
It sounds as though your fog is registered as extending a distance behind the camera, and thus that points considered to be within that region of fog are in a fog that is increasingly distant from the camera, and are thus made dimmer.
How are you currently setting up your fog, and how are you arriving at the values that you use for the fog near and far values, if I may ask? Perhaps a little of your code might help, especially any sections that involve your fog and scaling, and any pushes or pops that you might be doing.
(By the way, instead of scaling the model, or changing the viewport, why not change the perspective - specifically, the view angle?)
It sounds as though your fog is registered as extending a distance behind the camera, and thus that points considered to be within that region of fog are in a fog that is increasingly distant from the camera, and are thus made dimmer.
How are you currently setting up your fog, and how are you arriving at the values that you use for the fog near and far values, if I may ask? Perhaps a little of your code might help, especially any sections that involve your fog and scaling, and any pushes or pops that you might be doing.
(By the way, instead of scaling the model, or changing the viewport, why not change the perspective - specifically, the view angle?)
Thanks Thaumaturge. That's an iteresting idea that might be I am seeing something that is behind the camera. I would need to check it somehow.
Unfortunately I cannot give you a code sample. This application went through many hands and it seems everybody was tweaking it in his own style. The only thing was commong among those developers that they preferred not to leave comments :-). The matrix manipulations are all over the code.
I cannot change the perspective as by design the zoom as well as any other transformation is applied to the model. The model can be saved in a file together with all transformations. OpenGL is just of one of many views on the model.
Is it possible somehow to get the current location of the camera as seen by the OpenGl ?
Unfortunately I cannot give you a code sample. This application went through many hands and it seems everybody was tweaking it in his own style. The only thing was commong among those developers that they preferred not to leave comments :-). The matrix manipulations are all over the code.
I cannot change the perspective as by design the zoom as well as any other transformation is applied to the model. The model can be saved in a file together with all transformations. OpenGL is just of one of many views on the model.
Is it possible somehow to get the current location of the camera as seen by the OpenGl ?
Urk. o_o;
It sounds as though you've ended up in a pretty unpleasant situation.
As to retrieving the OpenGL camera position, it does appear, from what I've found in the OpenGL Blue Book, to be possible to extract the projection matrix (passing in the value "GL_PROJECTION_MATRIX" - sans inverted commas, of course), but even if you do get that, I'm not sure that it'll reveal the problem.
There are, I suspect, a few things that could be causing this problem - the near clip plane being set to a negative number, to allow the model to be rendered even when part of it extends behind the camera, for example, might do it, I think.
Again, I think that you should be able to retrieve these values via the function that I linked to above.
That said, I would hope that the relevant data - such as the camera position - is stored somewhere within the program.
A quick note: If the camera hasn't been moved or rotated, then it should be located at {0, 0, 0}, and be pointing down the negative z-axis, if I'm not much mistaken.
From what you've said, it sounds to me as though the base problem, however, is that you've had a number of people fiddle with the code, not document what they've been doing, and perhaps even work at cross-purposes.
I suggest that you consider one of:
I do hope that I'm wrong, and that a simple answer presents itself, and that it's not as worse as it sounds to me. To be honest, I don't think that I'd be surprised to find that more problems come of code that's ended up in as big a mess as you seem to describe. :/
It sounds as though you've ended up in a pretty unpleasant situation.
As to retrieving the OpenGL camera position, it does appear, from what I've found in the OpenGL Blue Book, to be possible to extract the projection matrix (passing in the value "GL_PROJECTION_MATRIX" - sans inverted commas, of course), but even if you do get that, I'm not sure that it'll reveal the problem.
There are, I suspect, a few things that could be causing this problem - the near clip plane being set to a negative number, to allow the model to be rendered even when part of it extends behind the camera, for example, might do it, I think.
Again, I think that you should be able to retrieve these values via the function that I linked to above.
That said, I would hope that the relevant data - such as the camera position - is stored somewhere within the program.
A quick note: If the camera hasn't been moved or rotated, then it should be located at {0, 0, 0}, and be pointing down the negative z-axis, if I'm not much mistaken.
From what you've said, it sounds to me as though the base problem, however, is that you've had a number of people fiddle with the code, not document what they've been doing, and perhaps even work at cross-purposes.
I suggest that you consider one of:
- Going through the code, either by yourself or, preferably, I would think, with another experienced coder - having more than one brain examining the code can help, I think - and trying to figure out what in all existence is going on in there. You may well end up changing some of what has previously been written.
- Going back to the original coders and getting them to tell you what they did.
- Dumping the current code and starting again.
I do hope that I'm wrong, and that a simple answer presents itself, and that it's not as worse as it sounds to me. To be honest, I don't think that I'd be surprised to find that more problems come of code that's ended up in as big a mess as you seem to describe. :/
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement