Z-buffering, depth-cueing on 4DGT

sabbagh sabbagh at acf5.NYU.EDU
Fri Oct 12 01:40:01 AEST 1990


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? 

Thank you.
Hadil G. Sabbagh
E-mail:		sabbagh at csd27.nyu.edu
Voice:		(212) 998-3125
Snail:		Courant Institute of Math. Sci.
		251 Mercer St.
		New York,NY 10012

"No talking to invisible people."
				- Sign in Top Dog, Durant Ave., Berkeley
Disclaimer: This is not a disclaimer.


P.S. The "IRIS-4D Series Graphics Library Reference Manual -- FORTRAN
77 edition (Version 2.0, Document #007-1206-020)" lies about the type
of arguments passed to lRGBra, namely,

	integer*2 rmin, gmin, bmin, rmax, gmax, bmax

should be

	integer*4 rmin, gmin, bmin, rmax, gmax, bmax

This was determined by using the only sure-fire diagnostic technique
on the IRIS: write a program according to the documentation, compile,
execute, brew coffee while the program dumps core. Examine (using dbx,
note that this is optional), rm core, correct and repeat.  Persons who
have low tolerance for caffiene should try fruit juice.



More information about the Comp.sys.sgi mailing list