sabbagh@acf5.NYU.EDU (sabbagh) (10/11/90)
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@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.
kurt@cashew.asd.sgi.com (Kurt Akeley) (10/12/90)
In article <1256@acf5.NYU.EDU>, sabbagh@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
sabbagh@acf5.NYU.EDU (sabbagh) (10/12/90)
In article <1990Oct11.194811.26512@odin.corp.sgi.com> kurt@cashew.asd.sgi.com (Kurt Akeley) writes: >In article <1256@acf5.NYU.EDU>, sabbagh@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@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