Hi,
I am drawing several objects in to the scene, using triangle strip and gl lists.
One of the objects is a tube.
Another object is a ring surrounding the tube.
I have the following problem:
From almost every angle I see the ring object with distortions, that is, the object becomes semi transparent in some parts of the object,
In a non uniform changing way(big line wholes that change their location according to the angle or distance that the object is turned to), I am sure the
model is fine since if I use a big zoom to the location of the ring I see the ring great.
Some facts:
The color alpha level of the ring is 1.0 and I am not using any blending function while drawing it.
The ring is actually the tube coordinates at a given location, that are being moved in the direction of the triangle Normals.
If I don’t move the ring vertices and leave them as they are of the tube I don’t see them at all.
(which is strange since I call the display list of the tube before the display list of the ring…is it suppose to be like that ?
does the order of the display lists calls counts ? does the order of the creation of the display lists counts ?)
If I move them in the negative side of the Normals I see them inside the tube and resolve the same visibility problem.
I checked it in two computers to make sure it’s not a driver problem (one with an ATI card and one with geforce-3) – same problem.
Any ideas ?
Thanks in advance.
z fighting be your problem…try moving your frustum near plane out to, say, 1.0
knackered you are a life savior !!!
1.0 was better but still a little distorted, but 2.0 did the trick….
Can you please explain ? what the hell is the connection of the frustum near plane that lets the gl engine to clip out objects before the plane, to visibility of objects
after affine transformation ??? is it a gl bug ? am I missing something ?
thanks a lot any how !!!
p.s
the near plane was at 0.1 in my app
Glad that solved it.
It’s all to do with depth buffer precision - the greater the difference between your near plane and your far plane, the less precise the depth values are. The ring and the tube are very close to each other, and as the rasterizer plots each pixel of the ring, it may have exactly the same depth value as the pixel already in the colour buffer - so depending on how your depthtest is set up, it may reject or accept that the pixel is in front of the tube.
There’s better explainations of this in other posts - search this forum for posts containing the phrase “z fighting”.
It is a problem when you’re doing some kind of flight simulator (of which I’ve done a few). You’re in the cockpit, but you can see right to the horizon…you need the near clip plane to be really near to avoid clipping out the cockpit polys, but you also need the far plane to be a heluva distance away, and you also have lots of land features such as houses, hangers, and BLOODY RUNWAYS which, if layered on the landscape like a decal, will give you unbelievable flickering z fighting artifacts…the solutions to this are very messy, in my opinion, but absolutely neccessary…such as rendering the cockpit last with a different z range (very near clip plane, very near far plane), and reversing the depth test to avoid having to clear the depth buffer. But of course rendering the cockpit last means you can’t take advantage of modern hardware occlusion techniques, because you’ve already rendered what the cockpit occludes…compromises, eh?
[This message has been edited by knackered (edited 07-03-2002).]
isn’t it also card dependent ? I mean the size of the z buffer matrix is changing according to the type of display card isn’t it ? , and therefore the precession of the scene in big near-far planes…
what if we shall normalize all world coordinates to the [0,1] range ? would it make it better ? (logically it shouldn’t…the z matrix is clamped any how, but…)
Snowmaster, no, it wouldn’t make any sense to “normalize” everything to a depth of 1. If you would normalize your near and far clipping plane and with the same factor multiply your Z values, you should get 100% the same result.
The Z Buffer doesn’t work linear, but a logarithmic way. So the Z-buffer in front of you is very exact, but there for as bigger the distance of the vertex to the observer is as more unexact everything gets. And if you set your near clipping plane very close to yourself, so use values like 0.1 for near and 10000 for the far clipping plane, even things just some meters away from you already Zfight like hell. I’m used to set nearclip to 10.f and farclip to 9000.f and this works very fine for me.
BlackJack