From guest Tue Jun 7 16:56:39 1994 From: "Drew Hess" Message-Id: <9406071656.ZM6289@airy.arc.nasa.gov> Date: Tue, 7 Jun 1994 16:56:56 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: z-buffer and Performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR I am trying to set a record for the most questions asked on the info-performer list in one week :) 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. For starters, I know I've got to turn off multisampling on an RE2 pipeline in the perfly window (thanks Allan Schaffer). 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). Then there's pfClear() to worry about.... (maybe?) 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. 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. I don't care about real-time performance, though it would be nice to maintain it. Can I lrectread from the z-bufer at any state in Performer, or should I only do this immediately before/after pfDraw(), for example? 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? Thanks for your patience and for any help, -dwh- dhess@vision.arc.nasa.gov dhess@cs.stanford.edu From guest Tue Jun 7 17:48:38 1994 From: "Michael Jones" Message-Id: <9406071748.ZM8482@babar.asd.sgi.com> Date: Tue, 7 Jun 1994 17:48:17 -0700 In-Reply-To: "Drew Hess" "z-buffer and Performer" (Jun 7, 4:56pm) References: <9406071656.ZM6289@airy.arc.nasa.gov> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Drew Hess" , info-performer@sgi.sgi.com Subject: Re: z-buffer and Performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR On Jun 7, 4:56pm, Drew Hess wrote: > Subject: z-buffer and Performer :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@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Sun Feb 20 06:25:31 1994 From: "Ran Yakir" Message-Id: <9402201624.ZM4127@fred.bvr.co.il> Date: Sun, 20 Feb 1994 16:24:18 +0000 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: Zbuffer bug Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR Hi There is a known Z buffer bug in Reality Engine machines, that causes the zclear() command to clear the Z buffer to 0x7fffff00, even when getgdesc(GD_ZMAX) or getgconfig(GC_ZMAX) or getgconfig(GC_MS_ZMAX) ays that the Z max value is 0x7f800000. lsetdepth() has no effect on that too. Now, it seems that Performer does the same thing, i.e. clear the Z buffer to 0x7fffff00 regardless of anything. This could be OK if Performer would lsetdepth() to the same value. Right now it doesn't and an inconsistency occures if you try to interpret Z buffer data. Thanks Ran Yakir -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il