Z-buffering, depth-cueing on 4DGT

[sabbagh]

In article <1990Oct11.194811.26512 at odin.corp.sgi.com> kurt at cashew.asd.sgi.com (Kurt Akeley) writes:
>In article <1256 at acf5.NYU.EDU>, sabbagh at acf5.NYU.EDU (sabbagh) writes:
>|> ... [stuff deleted]
>|> 
>|> 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).
>|> 
>
>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.

I'm still confused.  Doesn't the lsetdepth() call above imply that 
any pixel I draw will have a screen z coordinate of either 0 or 1?
Suppose I draw a line from (0,0,0) to (4,0,10), the z buffer should have
values like:
	0 0 1 1
corresponding to the pixels in the line, right?  How does 
depth-cueing work in this case?  The pixels with z screen coordinates = 0
should have color [rmax, gmax, bmax] and those with  z =1 should have
[rmin, gmin, bmin] (or vice versa).

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.

i
n
e
w
s

f
o
d
d
e
r