zbuffer lrectread

[Robert Ringrose]

In article <1991Jun18.000218.5825 at thunder.mcrcim.mcgill.edu> peta at McRCIM.McGill.EDU (Peter Whaite) writes:
>In article <acas.676654349 at godzilla>, mpapp@ (Mike Papper) writes:
>> I have been trying to read the contents (of a small area) of the 
>> zbuffer using lrectread. All I seem to get is a smattering of
>> 16777216s (i.e. almost 2 * 8388607 i.e. 2 * 0x7FFFFF), sometimes
>> mixed in with other values.

... most of situation deleted ...

>I'd like to know the answer to this as well.

I'm not with SGI, but I'll give it a try (having done something similar
trying to generate global shadows for video).  We have a PI 4D/25.

>zclear() doesnt seem to write z-far values into the buffer.
>flag somewhere that effectively does this for the graphics engine, but,
>unfortunately, not for lrectread.

I haven't had a problem with this delay (although you aren't alone - our
PI does it too :-) )  since we draw enough polygons that it has time
to complete the clear asynchronously.  You might try the finish() command
or even a delay statement to check this out.

The reason for "garbage" in the zbuffer:

One the PI, the zbuffer is _signed_ 24 bits.  Check GD_ZMAX and GD_ZMIN.
Since C doesn't have a 24-bit signed integer which really takes 32 bits,
here's what I did to "decode" the z buffer:

1) read the z buffer
2) for every point which will actually be used I sign-extended it with
	if (zval & 0x800000)
	  zval - zval | 0xff000000;
   where zval is a (signed) long set equal to the zbuffer value.

This has worked on a VGX and an IBM RS6000 (although the RS6000 had a problem
with clear not finishing before the drawing started).



Anyone found a better way?


BTW, I found snoop (in demos) a very handy tool for debugging this problem.



SGI : how about a pixmode option which works on the PI and causes it to
do the sign-extend as it loads from the zbuffer?


Robert Ringrose
ringrose at ai.mit.edu

"There's always one more bu6."