Re: decolorize callback

New Message Reply Date view Thread view Subject view Author view

Jim Helman (jimh++at++surreal)
Mon, 06 Feb 95 12:50:28 -0800

The ISECT process is created at pfConfig time. Like the CULL and APP
processes, it has its own copy of the libpf scene graph, but shares
leaf geometry (e.g. pfGeoSets which are not mulitbuffered.) If you
are changing vertices every frame, it's the application's
responsibility to avoid data collisions. 2.0 will make this easier
through the pfCycleBuffer for geometric arrays.

The ISECT process is flexible in that you can make your own calls to
pfSegsIsectNode in the IsectFunc callback without holding up the
application processing by pfFrame. You can also sproc off your own
threads if you want more parallelism.

The application can communicate the results back to the application
process however it likes. 2.0 will allow you to make copies of pfHit
structures to hand them back to the application process more easily.

The ISECT process' scene graph is not updated until the next pfFrame
after you finish your pfSegsIsectNode calls and return from the
IsectFunc callback. It is asynchronous in that pfFrame does not wait
for the IsectFunc callback to return. If you actually want to hold
off the triggering of the next fame until the isect is finished, you
could add a completion check before calling pfFrame.

rgds,

-jim helman

jimh++at++surreal.asd.sgi.com
415/390-1151

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:50:56 PDT

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