Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!goanna!minyos.xx.rmit.oz.au!godzilla!mpapp From: mpapp@ (Mike Papper) Newsgroups: comp.sys.sgi Subject: Re: zbuffer lrectread Keywords: lrectread readsource SRC_ZBUFFER zbuffer Message-ID: Date: 20 Jun 91 01:01:21 GMT References: <1991Jun18.000218.5825@thunder.mcrcim.mcgill.edu> <16539@life.ai.mit.edu> Sender: usenet@minyos.xx.rmit.oz.au (Njuiz noveles nova newes) Organization: RMIT Computer Centre, Melbourne Australia. Lines: 26 I fixed my zbuffer problem. The reason I was getting the "far" values was because I was "writing" to the zbuffer inadvertently, while drawing in the POPUP planes with the zbuffer on. (I had been using a "square magnifying glass" in the POPUP planes of my window to decide what area of the zbuffer to read. The initial zclear put in the far values, and as I moved the magnifying glass, the zbuffer was written to (there is no zbuffer mode in these planes, so results are unpredictable). Note that I did not have to convert my 24 bit integers to 32 (z buffer lrectread values should always have 0s in top 8 bits -- the manual also says this -- haven't tried on a VGX though). I did not have to use zdraw, only readsource. The only question I have now iss why zclear doesn't set the zbuffer to the highest lsetdepth value (it ALWAYS sets it to 16000000 or so). I ,suspect this is for efficiency, zclear deals with bitplanes and doesn't look at the rest of the GL state. Thus even on a GTX with z buffer range 8,000,000 to -8,000,000 zclear gives 16,000,000 (all values approximate). Subsequent writes to zbuffer (via drawing routines) does give values within the lsetdepth range. Mike Papper mpapp@godzilla.cgl.rmit.oz.au