Z-buffering, depth-cueing on 4DGT

Kurt Akeley kurt at cashew.asd.sgi.com
Fri Oct 12 05:48:11 AEST 1990


In article <1256 at acf5.NYU.EDU>, sabbagh at acf5.NYU.EDU (sabbagh) writes:
|> Hello:
|> 
|> I have been using IRIS 4D80GT and 4D25GT workstations for three years
|> now.  I have read, reread, rereread, ... TFM and STILL do not
|> understand how the z-buffer mechanism works in conjunction with
|> depth-cuing.  In particular, consider the following C code fragment
|> (for the 4D25GT):
|> 
|> long znear, zfar;
|> short rmin, rmax, gmin, gmax, bmin, bmax;
|> /* Might be long rmin, rmax, ...; see below. */
|> 
|> znear = 0x000000;
|> zfar  = 0x000001;
|> rmin  = 0x00;  rmax = 0xff;
|> gmin  = 0x00;  gmax = 0xff;
|> bmin  = 0x00;  bmax = 0xff;
|> ...
|> lsetdepth(znear, zfar);
|> ...
|> depthcue(1);
|> lRGBrange(rmin, gmin, bmin, rmax, gmax, bmax, znear, zfar);
|> ...(drawing routines go here).
|> 
|> This seems to do smooth depth-cueing; changing znear, zfar seems to
|> have little effect, except in the case when znear=zfar=0.  I don't
|> understand this, and the manuals are somewhat terse about depth-cueing
|> (100 words or less).
|> 
|> Could someone (even from sgi) explain exactly how this works? 

lsetdepth() maps clipped z coordinates (in the range -1 through 1) to screen
z coordinates.  lRGBrange maps screen z coordinates into RGB triples.  Thus,
in your example, ANY choice for znear and zfar, except choices having znear
equal to zfar, will produce exactly the same depthcueing result.  The
intermediate coordinate system (screen coordinates) doesn't matter, as long
as it is well defined.

The intermediate coordinate system DOES matter if the zbuffer is being used
to eliminate obscured pixels, rather than simply as an intermediary between
clip coordinates and color coordinates.  In this case, lsetdepth() should be
called with a range that optimizes the usage of the hardware zbuffer.  Since
its range is that of a 23-bit unsigned integer (on your GT system), lsetdepth
should be called with arguments 0 and 0x7fffff.  This has no effect on the
operation of lRGBrange, as long as it too is called with these arguments.

The reason that lRGBrange takes znear and zfar arguments is that it can be
made to map only a subrange of the lsetdepth() mapping.  A graph is probably
the best technique to illustrate this usage:

         rnear +    ------
               |           \
               |             \
               |               \
          rfar +                 -----
               |
               ----+-----+------+-----+--------
      lsetdepth:znear                zfar
      lRGBrange:       znear   zfar

In this way a piecewise-linear mapping of screen z to color can be made.

-- kurt



More information about the Comp.sys.sgi mailing list