Michael Jones (mtj++at++babar)
Tue, 7 Jun 1994 17:48:17 -0700
:I am trying to set a record for the most questions asked on the info-performer
:list in one week :)
That's what the mailing list is for.
:I am hacking the perfly source in an attempt to read z-buffer values for the
:currently displayed frame. At this point I'm a little overwhelmed by the
:number of parameters that seemingly can have an effect on the z-buffer at any
:given time in Performer.
Never fear. Info-Performer's here.
:For starters, I know I've got to turn off
:multisampling on an RE2 pipeline in the perfly window (thanks Allan Schaffer).
True. You can't read the multisample Z value.
: It also seems that pfESkyMode affects the z-buffer (PFES_SKY_GRND should set
:the z-buffer to a known state, which is what I want, I think).
All of the clear modes except PFES_TAG will reset the Z-buffer. If your image
looks good, then the Z-buffer's in a happy state.
:Then there's pfClear() to worry about.... (maybe?)
The earth/sky model does the pfClear for you. You can ignore this detail.
Just read the Z-buffer *after* calling pfDraw() in the channel draw
callback. Look for "PostDraw()" since you're using perfly.
:According to the readsource() man page,
:I should also make sure that drawmode() is NORMALDRAW, which shouldn't be a
:problem as long as I don't try to read the z-buffer while any GUI elements are
:being drawn.
Fine.
:Ideally, here's what I want to be able to do:
:
: readsource(SRC_ZBUFFER);
: n = lrectread(...., zbuf);
: /* operate on values in zbuf */
:
:I'd like to get the z-buffer that corresponds to the frame currently being
:displayed in the viewport. If I'm viewing a runway with a jet and buildings
:and mountains in the distance, I want to have the correct depth values for
:these objects.
This is what you'll get.
:I don't care about real-time performance, though it would be
:nice to maintain it.
It goes pretty fast. Something similar is used in the "view depth complexity"
mode of the statistics. Check out perfly with the stats set to "fill stats" for
an example of reading the stencil bits and then writing a pseudocolor image.
:Can I lrectread from the z-bufer at any state in Performer, or should I only
do
:this immediately before/after pfDraw(), for example?
You can read the Z-buffer whenever you want. It will be represent the
exact state of rendering at the moment the call is made. In practice, you
will *want* to read it just after the pfDraw() call. The only way to read
the Z-buffer "in the middle of things" is to bind a node draw callback to
something in the database and read the Z-buffer from with that callback.
:I believe that on an MP
:machine, Performer will render multiple frames on different processors to keep
:up with the requested frame rate; does this mean that the z-buffer could be in
:an inconsistent state?
Nope. The multiple frames that will be in process will be in the application
and
culling stages, not in drawing, so there'll be no graphics effect. You *will*
need
to read the Z-buffer from the draw process, which makes the channel draw
callback function the natural spot.
:Thanks for your patience and for any help,
Sure.
You've not mentioned it, but it will save you time if you consult the little
equation below. This is how to interpret (decode) the Z-buffer values which
you are seeking. It can be tedious to work out by hand. ;-)
z = value in z buffer after rendering (input)
range = distance to pixel in database units (output)
np = distance to near clipping plane (database units)
fp = distance far clipping plane (database units)
nz = near-clip z value (lsetdepth)
fz = far-clip z value (lsetdepth)
where you (or Performer on your behalf) did:
lsetdepth(nz, fz);
you must evaluate this equation for each Z-buffer value:
fp*np(fz-nz)
------------
fp-np
- range = --------------------------
(fp+np)(fz-nz) fz+nz
z - -------------- - -----
2(fp-np) 2
--Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj++at++sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:19 PDT