Allan Schaffer (aschaffe)
Tue, 11 Jul 1995 18:52:31 -0700
Ah-ha --
In addition to turning the Z buffer on again, you need to re-allocate
some bits for it to use. Calling getgconfig(GC_BITS_ZBUFFER) should
reveal that you were actually being given 0 bitplanes for the Z
buffer.
Why? When multisampling, it's recommended to free up the framebuffer
bits which would have been your standard Z-planes, so they can be
used otherwise. Performer does this automatically when you set up a
window, and will do all the necessary reconfiguration if you
enter/exit multisample mode [ie, via pfAntialias()]
I think this should do it:
> drawmode(NORMALDRAW);
> multisample(FALSE);
> zclear();
> zbuffer(TRUE);
> zfunction(ZF_ALWAYS);
zbsize(24);
> pixmode(PM_ZDATA,1);
> readsource(SRC_ZBUFFER);
> pfDraw();
> pixmode(PM_ZDATA,1);
> readsource(SRC_ZBUFFER);
> lrectread(...)
zbsize(0);
> 1) If I set the earthsky mode to PFES_SKY_GRND (as it is set in perfly),
> I have no problems. The zbuffer is read correctly.
>
> 2) If I set the earthsky mode to PFES_FAST, then the zbuffer just has
> one constant value, ff00000, which is obviously wrong.
Yep, these have to do with interactions between EarthSky and
multisampling, and the missing call (zbsize) to restore the standard
Z buffer to a usable state.
For case 1, we are always in non-multisample mode and pfInitGfx() had
already configured the window to use the standard Z buffer via
zbuffer(TRUE) and zbsize(24), so everything works properly.
For case 2, it's an odd combination of mixing the multisample-mode
"TAG" clear with a non-multisampling window, and neglecting to
allocate some Z buffer bits.
Keep in mind, reconfiguring the framebuffer each frame (enabling &
disabling multisampling, and configuring the Z buffer) is expensive.
Allan
-- Allan Schaffer aschaffe++at++sgi.com Silicon Graphics http://reality.sgi.com/employees/aschaffe
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:51:41 PDT