z-buffer values

New Message Reply Date view Thread view Subject view Author view

Drew Hess (dhess++at++vision.arc.nasa.gov)
Thu, 28 Jul 1994 17:50:20 -0700


A few weeks ago I posted a request for info on dumping the Z-buffer of a
Performer channel. Well, I've finally gotten around to using that info and I'm
curious about something.

I'm using draw callbacks, so the first thing the draw callback does for this
channel is call pfClearChan(). The channel has no ESky model, so according
to the man page, pfClearChan() should clear the viewport to black (it does) and
reset the Z-buffer to its maximum value.

Now when I call getgdesc(GD_ZMAX) from the draw process (after Performer has
been initialized and the draw callback is invoked the first time), on this
Onyx/RE2 I get back the value 0x7F800000. However, after copying the Z-buffer
into a shared arena using readsource(SRC_ZBUFFER) and lrectread, my Performer
app process scans the dumped Z-buffer and finds that the maximum value in the
Z-buffer is actually 0x7FFFFFFF, which of course is the largest positive value
of a 32-bit long.

Shouldn't pfClearChan() be clearing the Z-buffer to the value of
getgdesc(GD_ZMAX)? Do I need to do something like lsetdepth(getgdesc(GD_ZMIN),
getgdesc(GD_ZMAX)) when I initialize the channel?

Antialiasing is off, and calls to getgdesc from the draw process show that
Performer is configuring the channel with 12-bit color planes and a 32-bit
Z-buffer as the manpage for pfAntialias() says it should when AA is off.

Thanks for any insights,

-dwh-
dhess++at++vision.arc.nasa.gov


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:25 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.