Re: Perf drawing order

New Message Reply Date view Thread view Subject view Author view

Michael T. Jones (mtj++at++babar.asd.sgi.com)
Thu, 25 Jul 1996 15:26:52 -0700


On Jul 25, 12:14pm, Dewey Anderson wrote:
> Subject: Perf drawing order
>
> Does anybody know what determines the drawing order for Performer, and if
> there's any way to control it? We're looking for a way to get around not
> having a Z-buffer in some applications.

...

> I was hoping that the statement in the manual that traversal happens
> left-to-right would apply to drawing as well but my example seems to indicate
> that the drawing order can change.

That's the order that the Application and Cull traversals take through
the scene graph, but may not be the order of drawing due to mode sorting
in the cull process (as Kowsik mentions in his posting).

> Is there any way to control this?

Absolutely. Places to look:

   pfChannel cull mode (as in PFCULL_SORT)

   Sort "BINS", a major recent Performer feature, can be used
   to solve this problem. Check out pfChanBinOrder on the man
   pages. Pay close attention to "PFSORT_BACK_TO_FRONT". Note
   that there's even sample code for this.

> I can imagine that no one ever expected
> performer to be used in a situation where there is no depth buffer so I
> wouldn't be surprised to hear that it's not consistent or controllable.

Not so. In fact, some very advanced new technologies for prioritized
rendering (beyond binary separating planes) have been implemented in
Performer for some time now. This is more important on game consoles
than on SGI workstations, but perhaps we should release this work for
people like Dewey who run without Z-buffering.

Michael Jones

=======================================================================
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:14 PDT

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