Although the Z-Buffer is *very* useful, there often will come a time when just relying on the z-buffer by itself is totally pointless. In this paper i would like to show you why this is so, and how you can avoid this.
The z-buffer sorts what to draw and what not to draw with a depth tag. If something is in front of it with a larger tag(distance) then it won't draw it. But there is one problem with this technique, if you use the z-buffer alone as a occlusion algorithm you are going to be in for some very slow fps.
If you have a large scene and a lot of objects which are directly behind each other, then the z-buffer will still do a Depth Test, even in these extremly trivial cases. To understand what i am talking about, i think an illustration will help me describe this.

As you can see, in the side view illustration, although all the spheres are aligned together, the depth test will still do a test on every pixel.  When you have large scenes in your application and you can't these kind of penlties which the z-buffer imposes, it is usually time to implement an occlusion algorithm.

What this type of algorithm does, is make it so the the z-buffer is not the first removal test for your vertex data. Your occlusion algorithm will run and do it's test on the current verex data to draw.
Decide what to draw and what not to draw, but it doesnt' do that drawing ;)
After all the trivial cases which your occlusion algorthm has sorted out, it is time to pass the vertex data for the z buffer to do it's final test (optional). Once that stage is completed you let the drawing begin. In computer graphics we often call this stage of processing vertex data the "backend". Heh, i think i should write a paper on back end versus front end ;)