so i’m developing a kinda cool program with c++/ogl, 9 files, each ranging from 100 to 800 lines. i built a … i guess you could call it alpha-preliminary build (winxp) and sent the exe to a frind to look at it. what i saw:
what my friend on win2k saw (approximately the same viewing angle):
ok; any ideas? i’m using glBegin(GL_QUADS); and tesselation for various parts. if you change camera position on my friend’s computer, you will get different parts of the rectangles visible; this particular camera position and viewing angle has … those particular chunks showing up.
Looks like z fighting to me. See how the parts farther away are missing more from the scene? I’d bet you were using a 24 bit z buffer on your machine, and your friend is using a 16 bit z buffer. Also, I bet you don’t have very nice values for zNear and/or zFar.
Yep it’s Z precision and near & far clip distances. Looks like your friends card uses fragment z for far clip somehow.
Push the near clip plane out, that should fix it but you may also have to push the far clip plane out a little bit .
wow … guess it’s one of those things you read about in the very beginning and then kinda forget about it; at least i did
i had it set to
gluPerspective(80.0, 1.0, 0.1,10000);
but i changed it to
gluPerspective(60.0, 1.0, 5.0,1000);
and told my friend to get the latest drivers
thanks for all the help; i’ll be back tomorrow if it doesn’t work
The far clip plane doesn’t matter much. It’s all in the near clip plane.
good point … i just looked back at fig 3-18 of the redbook
do you determine the optimum values based on the graphics card, or just … whatever feels reasonable?
The far clip can matter under some circumstances.
Looking at this again I realize that blue walls are being drawn, and the problem is walls zfighting with the room contents (I had thought the screen was just cleared blue before). So as I said before push the near out, but here’s the correction, DON’T push the far out. Pull the far clip plane in towards the back of the room.
Since we don’t know what your near and far settings are it may be true that the far clip plane position needs to be adjusted, but usually the near clip does have more of an impact on z fighting since most precision is spent near the viewer and it tends to fall off rapidly.
Dunno if you posted in response to my deleted post or the other guy’s but I deleted because I realized about the blue walls after reviewing the screenshot again and that changes everything. Determine the optimum values by sandwiching your model as tightly as possible with the clip planes. There is no universal optimum setting for clip planes, it depends on what you’re drawing and you can get undesirable interractions with fog on some hardware if you start moving them dynamically, especially if the near gets very close to the viewer.
[This message has been edited by dorbie (edited 12-13-2002).]
it was just a general question …
but having looked at the figure in the redbook, i realised that the zbuffer was on a log scale – hence the most accuracy nearest to the znear plane.
what originally confused me though is that i haven’t even touched the values for near and far clipping planes since i first started working on the program up until now; the clearing color is black, and it looked decent on my friend’s computer up until the point where i added the blue walls. in retrospect, there was some of this effect without the blue walls, but definitely not that much.
but then again, in the earlier versions, the eye was closer to the object being displayed …
pieces of the puzzle falling into place in my head
This is because it’s the blue walls fighting with the room contents as I said. It’s not a mystery, without the walls there is no z fighting and sawtooth because there’s nothing behind the machinery to fight with. When you add the walls the hardware doesn’t have the precision to discern between the depth of the walls and the depth of the machinery. The sawtooth effect is caused by the interpolation of Z at limited precision as the wall depth pops in front of and behind the interpolated depth of the machinery polygons.
[This message has been edited by dorbie (edited 12-14-2002).]