Re: Intersections and MultiProcessing

New Message Reply Date view Thread view Subject view Author view

Jim Helman (jimh++at++surreal)
Thu, 17 Nov 94 14:12:16 -0800

> 1) Can pfChanPick and pfSegsIsectNode be called from
> a node DRAW call back (pre and post)?
   
Not advisable. Since the DRAW process does not have a copy of
the scene graph, you'll be operating on the APP's copy. The
APPS's copy of scene graph could be in an inconsistent state
because of updates or changes going on in the APP. Also,
generally one wants to keep the DRAW's computational load as
low as possible.

> 2) Can pfChanPick and pfSegsIsectNode be called from
> a node CULL call back (pre and post)?
   
Not supported (see #3), but it would probably work in 1.2.

> 3) What does the Performer manual mean when it says that
> pfSegsIsectNode can only be called from the APP or ISECT
> processes?

It means that you should only call pfSegsIsectNode from the
APP or ISECT processes, i.e. you shouldn't try it in the CULL
or DRAW.

> I'm not sure when and where the ISECT process
> gets called. Does it get called during the cull or draw cull
> processes?
   
The ISECT process is a separate process with its own copy of
the scene graph. You access this process using a callback
specified pfIsectFunc() (this works in the same way that the
callbacks for pfChanCullFunc() and pfChanDrawFunc() get you
into the DRAW and CULL processes if any). Typically this
callback performs one or more collision tests and then returns.
The process has it's own copy of the scene graph and is
asynchronous, i.e. the culling/rendering pipeline does not
wait for the callback to return. Communication of the
intersection results is left to user code.

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:40 PDT

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