Yair Kurzion (yair++at++polygon.engr.sgi.com)
Mon, 6 Dec 1999 15:04:25 -0800 (PST)
> I have been attempting to sync several engines together for a
> Performer particle system animation. The resulting geoset has fluxed
> attributes. These attributes are stored in separate fluxes since
> some attributes are different types of data. All of these are
> connected to a timer flux from pfGetFrameTimeFlux. The engines need
> to sync together for each frame. What's the best way to ensure the
> order in which pfEngines are operated upon when they may use each
> others' outputs as sources?
pfFlux has a flag called PFFLUX_PUSH. When you set it to ON, any writes to this
pfFlux will trigger an evaluation of all the pfEngines that this pfFlux feeds.
By default, the pfFlux in pfGetFrameTimeFlux is a PUSH flux. This means that
every engine reading from this pfFlux (as a source) will evaluate itself every
time the pfGetFrameTimeFlux changes (== every Performer frame).
In your evaluation tree, the timer should probably trigger the velocity engine
but none of the other engines. So, you need a timer source that will not
trigger engine evaluation. I think the easiest way to get this is feed the
timer pfFlux into an engine that merely copies the source into a destination
pfFlux. Make the destination pfFlux not-PUSH, and use it in the rest of your
engines.
Make the velocity engine output a PUSH flux. This will trigger position
evaluation as a result of the velocity evaluation.
Since you want color to run after position (which runs after velocity), you
want to make sure that the velocity computation doesn't trigger a color
computation. You can do this by attaching a copy-engine to the velocity
output. This engine will copy the velocity result into a non-PUSH pfFlux which
you will feed to the color engine.
> I want velocity evaluated from the timer, then position evaluated
> from both the timer and velocity. Color uses the timer, velocity,
> and position. When the engines evaluating position and color are
> triggered, they require the values for the time and velocity to be
> for the current frame. The only way I have found to ensure this is
> by calling getWritableData instead of getCurData.
This may not work as you expect. When asking for writable-data, you often get
the oldest buffer in the system (similar to least-recently-used). The only case
where getWritableData returns a new buffer is if someone has already written on
this buffer for the current frame.
> This makes
> Performer throw a ton of warnings to the screen. I don't want to
> write to the data when using it as a source, but I do need to ensure
> that source is from the current frame. The fluxes are part of a
> syncGroup triggered after the color is evaluated. I seem to be
> running into conflicts due to attempting to grab invalid buffers, so
> motion of the system is really erratic. (eg. a smoothly ascending
> particle will 'bounce' erratically as it rises because frame buffers
> for position are incorrect.)
>
> The aqua example operates directly on attributes stored in shared
> memory and then copies those attributes into the geoset. I'm trying
> to take advantage of fluxes for multiprocessing by operating directly
> on fluxed attributes connected to the geoset, so things get a little
> more complicated. Any suggestions for which modes I need to set on
> the fluxes and engines for them to behave correctly? Or am I simply
> making this way too complex for a relatively minimal gain in
> performance? :)
The gain (I think) is in MP-safety. I am not sure how aqua works, but if it
modifies geoset attributes while they are drawn, you could get some funny
visual artifacts. This is especially true if you change the number of
primitives in a GeoSet.
The other potential gain is that you can run your computation in an
asynchronous Performer process (DBASE or COMPUTE). Setting up PUSH flags on the
different Fluxes, you can make sure that all the engines are evaluated in the
Asynchronous process and don't burden your APP-CULL-DRAW frame rate.
-yair
--
\_________ \_____ \__ \__ \_____ Yair Kurzion
\_________ \_____ \__ \__ \_____ yair++at++sgi.com
\__ \__ \____\__ \__ http://reality.sgi.com/yair
\__ \__ \__ Work: (650) 933-6502
\__ \__ \__ Home: (408) 226-9771
\__ \__ \__
This archive was generated by hypermail 2.0b2 on Mon Dec 06 1999 - 15:04:28 PST