Re: pfFCS

New Message Reply Date view Thread view Subject view Author view

Yair Kurzion (yair++at++polygon.engr.sgi.com)
Mon, 15 Nov 1999 13:14:22 -0800 (PST)

> 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
       \__          \__    \__

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Nov 15 1999 - 13:14:41 PST

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