3D Graphics - Game Programming Algorithms and Techniques - page 106

With z-buffering, the scene can be drawn in any arbitrary order, and so long as
there aren't any objects with transparency, it will look correct. That's not to say
that the order is irrelevant—for example, if the scene is drawn back to front, you
would overdraw a lot of pixels every frame, which would have a performance hit.
And if the scene were drawn front to back, it would have no overdraw at all. But
the idea behind z-buffering is that the scene does not need to be sorted in terms of
depth, which can greatly improve performance. And because z-buffering works on
a per-pixel basis, and not a per-object basis, it will work well even with the over-
lapping triangles case in Figure 4.16 .
But that's not to say z-buffering by itself solves all visibility problems. For one,
transparent objects won't work with z-buffering as is. Suppose there is semi-trans-
parent water, and under this water there's a rock. If pure z-buffering is used, draw-
ing the water first would write to the z-buffer and would therefore prevent the rock
from being drawn. To solve this issue, we first render all the opaque objects in
the scene using normal z-buffering. Then we can disable depth buffer writes and
render all the transparent objects, still checking the depth at each pixel to make
sure we aren't drawing transparent pixels that are behind opaque ones.
As with the representation of color, the z-buffer also has a fixed bit depth. The
smallest size z-buffer that's considered reasonable is a 16-bit one, but the reduced
memory cost comes with some side effects. In z-fighting , two pixels from differ-
ent objects are close to each other, but far away from the camera, flicker back and
forth on alternating frames. That's because the lack of accuracy of 16-bit floats
causes pixel A to have a lower depth value than pixel B on frame 1, but then a
higher depth value on frame 2. To help eliminate this issue most modern games
will use a 24- or 32-bit depth buffer.
It'salso important toremember that z-bufferingbyitself cannot guarantee nopixel
overdraw. If you happen to draw a pixel and later it turns out that pixel is not vis-
ible, any time spent drawing the first pixel will still be wasted. One solution to
this problem is the z-buffer pre-pass , in which a separate depth rendering pass is
done before the final lighting pass, but implementing this is beyond the scope of
the topic.
Keep in mind that z-buffering is testing on a pixel-by-pixel basis. So, for example,
if there's a tree that's completely obscured by a building, z-buffering will still in-
dividually test each pixel of the tree to see whether or not that particular pixel is
visible. To solve these sorts of problems, commercial games often use more com-
plex culling or occlusion algorithms to eliminate entire objects that aren't visible