Brian Furtaw (brian++at++sgi.com)
Tue, 16 Nov 1999 09:11:01 -0500
There are two good examples of using pfFlux and pfFCS combined with
pfEngines in /usr/share/Performer/src/pguide/libpf/C++ the source files
are fcs_animate.C and
fcs_engine.C. Most of what you are going to be interested in is the
make_fcs routines.
Brian
Yair Kurzion wrote:
>
> > We are developing a flight simulator for an Onyx 2 with 30 some processors
> > in it. To utilize this architecture fully we would ideally have an the app,
> > cull, and draw stages in separate processes on separate processors and an
> > each airplane in the simulator running on its own process.
> >
> > So I would setup the scene graph in shared memory then fork off to my
> > airplane process. But the airplane process is going to be asynchronously
> > computing its position and needs a safe means to communicate that position
> > to the scene graph. Is this what the pfFCS is for?
>
> Hi There !
>
> An pfFCS is a matrix node (just like pfSCS and pfDCS). So I am assuming that
> your simulation processes generate a matrix for each airplane.
>
> Instead of a regular matrix, a pfFCS node contains a pfFlux. A pfFlux is a
> mechanism for propagating data changes among processes in a frame-accurate
> manner. In other words, if you write the pfFCS matrix in some process at frame
> n, it will only be visible to other process when they hit frame n. Before they
> do, they will see older versions of the matrix.
>
> For a non-Performer process to use a pfFlux, they should inform pfFlux of the
> current frame (man pfFlux::setFrame or pfFluxFrame). If you set the pfFlux
> frame number to be the App frame number at the beginning of each simulation
> frame, you can safely write into the pfFlux (pfFlux::getWritableData).
>
> For this to work correctly, your non-Performer processes should be forked from
> the Performer App process. If your processes share the data address space of
> the App process (as in sproc), pfFlux will not work correctly.
>
> You must note that when you change the pfFCS matrix, the pfFCS node is not
> informed and therefore it does not re-calculate its bounding sphere. This often
> results in incorrect culling (i.e. your object disappear from the screen when
> they should be visible). In your case, I think it would make more sense to use
> a pfFlux to pass the matrix contents from your simulation processes to the App
> process. Your App process should read the pfFlux every frame and modify the
> matrix in a pfDCS node that transforms your airplane models. When App changes a
> pfDCS matrix, it triggers a re-calculation of all the relevant bounding spheres
> and so culling is correct.
>
> -yair
>
> --
> \_________ \_____ \__ \__ \_____ Yair Kurzion
> \_________ \_____ \__ \__ \_____ yair++at++sgi.com
> \__ \__ \____\__ \__ http://reality.sgi.com/yair
> \__ \__ \__ Work: (650) 933-6502
> \__ \__ \__ Home: (408) 226-9771
> \__ \__ \__
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
--
----oOOo---- ----oOOo---- ----oOOo---- ----oOOo----
Brian Furtaw (brian++at++sgi.com)
Graphics Guru Office:(301)572-3293 Fax: (301)572-3280
12200-G Plum Orchard Drive OpenGL/Performer/OpenInventor/ImageVision
Silver Spring, Maryland 20904 Optimizer/React/PCI Device Drivers
This archive was generated by hypermail 2.0b2 on Tue Nov 16 1999 - 06:19:11 PST