Well, it depends of the size and position of the cube, and znear/zfar values. If you have a cube of 50x50x50 and znear=1/zfar=10, you''ll sure have a problem. Personnally, i have experienced problems with big distant objects and a 16 bit Zbuffer..
> For the Z-buffer I''m quite sure that Z-near is mapped to 000..000 and Zfar is mapped to 111...111 (in OpenGL).
Yes, you''re right.. but what i meant is that a (Znear+Zfar)/2 distance won''t be mapped to 100...000. You have more accuracy near the Znear. On the other side, you can have 2 points, one with z=Zfar, and another one with z=Zfar*0.8, mapped to the same value in the Zbuffer (111...111).
It''s not OpenGL specific. All hardwares i know of work like that.
> Anyway I had : gluPerspective(..., 0.1f , 900) and changed it to gluPerspective(..., 1 , 900 ) and it works ? Starnge !
Not really
It''s exactly the problem of loss of accuracy i described above. When you decrease the ratio Zfar/znear, your accuracy increases. With znear=0.1 and zfar=900, your ratio was 9000, wich is way too high for a 16 bits Zbuffer. So, let''s imagine what happened for the far faces of your cube: let''s say you have face 1 at a distance of 8000. Let''s say you have a face 2 at a distance of 7000. Now, pixels of these faces will be mapped at the same position in the Zbuffer. It means that, though the pixels are distant of 1000 units in world space, they will both pass the depth test. It results in weird artifacts, like the one shown in the screenshot.> so what about large worlds ?
First solution: do not use large worlds (why is the horizon so close in most games ? Why do game developpers abuse so much of the fog effect ?).
Second solution: use a 32 bits Zbuffer, but your game won''t work well with old hardware using 16 bits Zbuffer.
Third solution: use a trick. Divide your space in two, sort your objects, set the zbuffer to znear=X and zfar=Y/2 for the first half-space and clear it, render the objects of this half-space, set the zbuffer to znear=Y/2 and zfar=Y and clear it, and render the objects in the second half-space.
But it''s slower than the first and second solutions..
Y.
