From: mark@austin.ibm.com (Mark Einkauf)
Subject: Re: Z Buffer Precision and Homogeneous Coordinates
Originator: mark@einkauf.austin.ibm.com
Date: Wed, 16 Dec 1992 21:13:43 GMT
Organization: IBM Austin


In article <78173@hydra.gatech.EDU>, gg10@prism.gatech.EDU (GALLOWAY) writes:
>                       B
>     Z(screen) = A + ------
>                     Z(eye)
> 
> where A and B are constants.  And that this is done so that "in moving
> from eye space to screen space, lines transform into lines and planes
> transform into planes."  The depth value gets normalized from the range
> [near, far] to [0, 1].
> 
> If the viewing transformation matrix consists of only linear operations,
> translation, rotation, and scaling, then this appears to degrade the
> precision of the depth value.  In my current Z buffer-based renderer my
> Z buffer is an array of 32 bit floats.  I preform clipping in the 3D view
> space (or eye space) before perspective projection.
> 
> My questions are:
> 
> a) Why do software (non-hardware) Z buffers normalize the depth value?
>    Why not just keep around a float and compare floats?
		
     Compares are OK for clipping to a rectangular volume, but the trouble
     comes when trying to clip to a frustum (truncated pyramid) - which is 
     what you must do if you want a perspective view (as opposed to parallel).
     There, you want the equations of the planes of the frustum to be very simple
     so your intersection calculation is in turn simple (and therefore fast).
     Likewise, even in a parallel view, if your transforms are such that the 
     view volume is a nice normalized cube (0->1, or 1->1 on all sides) then you can
     use the same equation for finding intersections.  You are then always intersecting	
     with 0 and 1 or 1 and 1, rather than arbitrary boundaries.

> 
> b) Are most Z buffers integerized as well?  How many bits?
>    What is the advantage?

     Hardware z buffers are integerized, just like the x,y coordinates of your
     display (i.e. there is no such physical pixel as x=145.982, y=389.004).
     In hardware, all there is is bits, so whether you say they are simple
     integers, or in an elaborate float format, your resolution remains the same and
     is determined by the actual number of physical bits per pixel.  Its simpler to
     treat everything as an integer.  Typical z buffers are 16 to 24 bits.
     The more bits, the greater resolution.  If too few bits, things that are actually
     separated in z may map to same hardware z value and interfere with each other.

> 
> c) When is the correct time to clip?  And are homogeneous coordinates
>    necessary if you are not current rendering NURBs?
>    For most surface, except NURBs, W is always 1 anyway, right?
> 
     If you have a perspective view, homogenous coordinates are convenient to
     use for clipping.  In the answer to (a) above, recall the frustum.  If you clip
     to the 3d frustum , you must apply the perspective after clipping, which means
     you need more math (takes time).  Foley and Van Dam show how these steps are 
     combined so that you apply the perspective transform before clipping, then
     clip to +/- w.  In this case, w is definitely not always = 1.  After clipping
     to +/- w, you divide x,y,z by w which gets you to your normalized cube.  After
     this divide, w is 1 and you can breathe a sigh of relief - you have survived 4
     dimensions.  From the normalized cube you apply your device scale/translate
     to map to the physical window.  


-- 
  Mark Einkauf     [ mark@einkauf.austin.ibm.com (only valid within ibm.com) ]
  IBM-AWD Graphics [ VNET EINKAUF@AUSVM6                                     ]
  Austin TX        [                                                         ]
 * Views and opinions expressed herein are not necessarily those of IBM Corp. *