Jim Helman (jimh++at++surreal)
Sat, 24 Sep 94 18:52:33 -0700
In an MP environment, you could do the same in the DRAW process, but
this takes time away from rendering, so it's best to modify the data
in the APP (in the non-latency critical section after pfFrame, but
before pfSync). But since libpr objects are not automatically
multibuffered, this means you must be careful to avoid changing the
vertex arrays while the DRAW is drawing from them, or you may see
the geometry tear. The easiest way to avoid MP data collisions is
with multiple copies so you can update one copy in the APP while the
DRAW is working on another. Just create a pfSwitch node with three
copies underneath it (three copies is usually enough for a three
stage APP+CULL+DRAW software pipeline). In the APP, set the switch
node to the "next" child and update the geometry for that child.
The only trick is deciding who's next. Using child = (child+1)%4 in
the APP each frame works well in the absence of frame extensions.
You can protect against DRAW extensions by incrementing the child
count one more if the DRAW happens to be working on the chosen child.
In general, covering all the bases to guarantee no collisions in any
phase with multipipe operation and frame extensions can get nasty.
So, we'll be making MP-safe dynamic geometry easier in 2.0.
rgds,
-jim helman
jimh++at++surreal.asd.sgi.com
415/390-1151
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:33 PDT