Michael T. Jones (mtj++at++babar.asd.sgi.com)
Thu, 25 Apr 1996 07:09:55 -0700
Note that a new feature in IRIS Performer 2.0 was the ability to have
separate cull and viewing volumes for just this reason. Its documented
in the man pages but the best example is to see what happens when the
'z' key is pressed in Perfly -- look at that code for an example.
: I've managed to achieve the over culling, and the insertion of the view
: position into the DRAW using pfLoadMatrix in the draw callback. However,
: the problem I'm facing now is the synchronization between the APP and
: the DRAW. This is particularly important when dealing with multiple
: channels and pipes which need to stay in sync. Basically I need to
: somehow ensure that the DRAW gets the latest view position that the APP
: has received, but at the same time for multiple channels and/or pipes, I
: need to make sure that all the DRAW stages get the view positions from
: the same sample time in the APP, otherwise the views will drift.
You have view position as a per-frame update stream from a head-tracker
and simply need to get that value consistently in all channels and in
all pipelines. The Performer channel pass-through data is not what you
need here. What you need would seem to be a time-stamped (or rather,
destination frame stamped) list of view parameters in shared memory
that is consulted in the channel pre-draw callback to update the view.
Note that since each channel on the same pipe is drawn consecutively,
just grabbing the latest parameters is not sufficient. You'll also
need to pay attention to the "frame id" which is something that you
should send down through the channel pass-through data mechanism.
: I've been looking at the Performer multi-process model, trying to
: understand how it behaves in the various phase modes, in order to try to
: find a solution to the problem above. In particular how it works when
: there are multiple channels and/or multiple CULL and DRAW processes.
: What exactly does pfSync and pfFrame do in these situations? How do the
: processes synchronize to each other?
Just remember that in LOCK or FLOAT mode entire frames will be dropped
after an overload-frame event. This is why simple incrementing of the
frame ID in the draw callback won't be enough. (Presuming that there
are one or more frame overruns. If not, then there shoud be no problem.)
: Any help, suggestions or comments would be greatly appreciated.
This approach can be made to work well. It's been used in theme-park
rides and other head-tracked applications.
Michael Jones
Be seeing you, Phone:415.933.1455 Fax:415.965.2658 M/S:8U-590
Michael T. Jones Silicon Graphics, Advanced Systems Division
mtj++at++sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311
"Du musst Amboss oder Hammer sein" -- Goethe
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:46 PDT