Large Outdoor Scenes
Author
Ok, this is the scenario:
I''ve got a rather large outdoor scene that I''m rendering. I''ve basically got a flight simulator where you can fly over an island. You can fly high above the island (view it from far away) or land on the ground (view it close up).
The problem is that I''m drawing the ocean using a very large semitransparent blue quad and, especially from far away, the quad will jitter up and down. The effect is VERY noticeable and ruins any claim my game has to graphic artistry.
I know that this problem is called Zfighting and has to due with the fact that the zbuffer has inadequate precision (though I am using 24 bits). I also know that the precision is nonlinear and that 90% of it is used in the first 10% of the distance between the camera and the far clip plane (which has to be rather far away, since the scene is large). I also know that the recommended solution is to put the near clip plane as far away from the camera as the game will allow. This has not worked very well for me.
I notice that games like MS Flight Simulator render similarly large scenes without this zfighting problem (or without visible effects, at least). So, I would like to hear from anyone who has had a similar problem and how they fixed it. What were your settings for the near and far clip plane? Is there a clever way around with problem without doing two rendering passes?
Why do graphics cards only support 24 bit zbuffers when it''s obvious they aren''t good enough? Shouldn''t it be possible to use an arbitrary bit depth? Obviously I don''t appreciate the complicated nature of designing graphics hardware.
----------------------------------------
Let be be finale of seem, seems to me.
----------------------------------------
Coding:
http://www.stanford.edu/~jjshed/coding
Miscellany:
http://www.stanford.edu/~jjshed
I give you some idea (perhaps stupid...)
One solution is to draw ocean first without Z writing (disable Z writing glDepthMask(0))
If you have to draw something underwater draw this first, then ocean then island.
To reduce Z noise you should reduce the ratio Zfar/Znear.
Avoid ''polygon-Z-fighting'' (make polygons orthogonal).
Another solution is to draw a little ocean-quad that ''follows'' the camera; to ''move'' the quad translate the texture.
z buffer is expensive! Z buffer is expensive to mantain and to clear (few years ago every 3D games used 16bit zbuffer!incredible...).
Probably there are cards supporting 32 bit. No, you cannot specify an arbitrary depth (perhaps on super-pro cards...).
One solution is to draw ocean first without Z writing (disable Z writing glDepthMask(0))
If you have to draw something underwater draw this first, then ocean then island.
To reduce Z noise you should reduce the ratio Zfar/Znear.
Avoid ''polygon-Z-fighting'' (make polygons orthogonal).
Another solution is to draw a little ocean-quad that ''follows'' the camera; to ''move'' the quad translate the texture.
quote:
Why do graphics cards only support 24 bit zbuffers when it''s obvious they aren''t good enough?
z buffer is expensive! Z buffer is expensive to mantain and to clear (few years ago every 3D games used 16bit zbuffer!incredible...).
quote:
Shouldn''t it be possible to use an arbitrary bit depth?
Probably there are cards supporting 32 bit. No, you cannot specify an arbitrary depth (perhaps on super-pro cards...).
quote:Original post by Telamon
Why do graphics cards only support 24 bit zbuffers when it''s obvious they aren''t good enough? Shouldn''t it be possible to use an arbitrary bit depth? Obviously I don''t appreciate the complicated nature of designing graphics hardware.
Well 24 (and 16 usually) is good enough for most purposes, you just need to be a little careful if you''re working with huge distances.
It isn''t possible to use an arbitrary bit depth because the zbuffer is usually interleaved with up to 8 bits of stencil buffer (which makes it run nice and concurrent with a 32bit colour buffer).
This is a *lot* of memory we''re talking about here, and video card memory is fast, and thus expensive and only avalible in limited amounts. A game running at 1024x768 needs 1024x768x4x2 (color) + 1024x768x4 bytes just to run double buffered. Thats a whopping 9.5Mb before we even have to think about textures and geometry that also want graphics card memory. And theres plenty of people running at higher resolutions..
Higher zbuffer and colour depths are comming though, but it''ll be a while before they''re mainstream.
w-buffer
stenciling
I seem to recollect something along these lines being dealt with one of these concepts.
stenciling
I seem to recollect something along these lines being dealt with one of these concepts.
ooh ooh!
and a back to front drawing order and eliminate the z-buffer all together.
I''m assuming you are using an oct-tree?
and a back to front drawing order and eliminate the z-buffer all together.
I''m assuming you are using an oct-tree?
Chunked z-buffering.
Roughly sort your geometry into 3 distinct depth regions: near, medium, far. You can use more, but three are usually enough. Render each region separately, from back to front, clearing the depth buffer between each region. This essentially gives you a 72 bit depth buffer (well, if the value distribution was linear, which it is not, but you get the idea). This concept can be expanded at will, giving you good accuracy with low depth buffer resolution over virtually infinite distances.
Roughly sort your geometry into 3 distinct depth regions: near, medium, far. You can use more, but three are usually enough. Render each region separately, from back to front, clearing the depth buffer between each region. This essentially gives you a 72 bit depth buffer (well, if the value distribution was linear, which it is not, but you get the idea). This concept can be expanded at will, giving you good accuracy with low depth buffer resolution over virtually infinite distances.
The problem is not Z-fighting -- that''s a specific case of two polys with insufficient separation for the given view for the depth test to resolve front/back for all pixels when they get rasterized.
However your problem does sound like a floating point precision issue. You didn''t mention texture, but large polys generally have problems with texture "swimming" that is caused by insufficient precision when doing texture interpolation. Assuming no texture, my guess would be that at the clipping stage you are running into precision problems resulting from, for example, division of large values by small values.
However your problem does sound like a floating point precision issue. You didn''t mention texture, but large polys generally have problems with texture "swimming" that is caused by insufficient precision when doing texture interpolation. Assuming no texture, my guess would be that at the clipping stage you are running into precision problems resulting from, for example, division of large values by small values.
I think ive had that same jitter problem. I had one big quad for my entire ocean, but i just replaced the big quad with many smaller quads.
That fixed that.
That fixed that.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
