re: layers

New Message Reply Date view Thread view Subject view Author view

Michael Jones (mtj++at++isdn-celeste.corp.sgi.com)
Tue, 22 Oct 1996 06:27:13 -0700


Bill Marinelli wrote:

| I notice that if I model coplanar polygons in multigen with the
| following hierarchy ....
|
| g1
| |
| |
| o1
| |___________
| | | | | |
| p1 p2 p3 p4 p5
|
| then I run into the typical z buffer resolution problems that one
| would expect with coplanar when I diplay the geometry in perfly.

Yes. You have said "here are five polygons. draw them in any order and
resolve them with the Z-buffer". Since they are coplanar in spirit,
but not in the finite precision of any floating point number of any
resolution (32-bit, 64-bit, 5000-bit, ...) the Z-buffer can never
resolve these consistently. Instead, we need a hint.

| OTOH if I model the same geometry in with this hierarchy....
|
| g1
| |
| |
| o1
| |
| |
| p1 (ground)
| |
| |
| p2 (airstrip)
| |_____
| | | |
| p3 p4 p5 (stripes)
|
| ...then the problem simply goes away. Hence we don't have to model the
| roads 6 feet above the ground (MTJ might still get a little passionate
| when he hears about this) or play with the near/far clip. The
| performer scene graph seems to indicate that this modeling technique
| generates some sort of layer in perfly.

Exactly correct. You have now let the hardware (via MultiGen, Performer,
and IRIS GL/OpenGL) in on your secret: that a fixed-ordered layering
relationship exists between sets of these five polygons: the ground
is BELOW the airstrip which is BELOW the stripes. You let us know the
score, and we'll do the right thing!

| Question - is the reason for this because the loader recognizes the
| "parent/daughter" polygons and invokes pfLayer or is it some other
| sort of magic?

It's exactly as you first suggest--subfaces in multigen imply *exactly*
the ordering that we need to know. (FYI, take a look at your database
in Perfly and press the "h" key to see the scene-graph structure. You'll
see that layer nodes have been built from the input geometry. If you
pick things in that mode, the scene-graph will slide to show the selected
object, and if you pick the node in the display, the object in the
scene will be highlighted. It's a handy feature...)

In the case above, IRIS Performer will do one of the following (depending
on the pfLayerMode selected):

Stencil:
  enable z-buffer
  enable "set stencil based on z pass/fail"
  draw p1
  disable z-buffer
  enable "draw where stencil is set" (e.g. where the ground was visible)
  draw p2
  draw (in *any order*) p3, p4, and p5
  disable stencil
  enable z-buffer

  This is the exact rendering order and can not be changed.

Displace:
  A: draw p1 without displacement

  B: set a displacement toward the eye of 1 lsb of Z
     draw p2 with displacement enabled

  C: set a displacement toward the eye of 2 lsb of Z
     draw p3, p4, p5 (in *any order*) with displacement enabled

  Note the advantage of displacement: the phases A, B, and C can happen
  in *any* order. Sorting by texture and light model as is the default
  in Performer will likely as not permute the order from A,B,C in the
  quest of speed. This is a luxury not allowed Performer by the stencil
  approach, but it works fine here.

Reference Plane:
  A: draw p1

  B: draw p2 using the plane equation of p1

  C: draw p3, p4, p5 (in *any order*) using the plane equation of p1

  A different set of restrictions are in force here. Performer *must*
  draw them in the order A,B,C but we're free to draw anything we want
  before, during, or after doing so:

     stuff, A, stuff, B, stuff, C, stuff

  This is not as flexible as Displace, but is less restrictive than
  Stencil. We can still sort as long as the internal ordering of
  (possibly hundreds of) Reference Plane pfLayers is honored. For
  example, we could draw:

    A0, A1, A2, ..., B0, B1, B2, ..., C0, C1, C2, ...

  if there were hundreds of layers each as described in Bill's
  example where the ground, airstrip, and stripes had some
  common textures. Also, within the A's, the ordering is
  arbitrary (this applies mutatis mutandis to B's and C's as
  well).

Michael Jones

Be seeing you, Phone:415.933.1455 Fax:415.965.2658 MS:8U-590
Michael T. Jones Silicon Graphics, SSG--Advanced Graphics Division
mtj++at++sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311
120 Mario 64 Stars OpenGL/ImageVision/OpenInventor/Performer/Cosmo3D
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com


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:53:47 PDT

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