Re: pfFlux

New Message Reply Date view Thread view Subject view Author view

Yair Kurzion (yair++at++polygon.engr.sgi.com)
Tue, 12 Jan 1999 12:29:37 -0800 (PST)

> I have a design issue for the older and wiser heads amoung you. We are
> designing a Virtual Enviroment (CAVEApp) that has potentially many
> coordinate systems. These CoordDefs store a matirix that position the
> local coords in Graphic space. Graphical objects come in in Data units
> and are translated to Coord Space. They are drawn in local Coord space.
> It is quite a good solution for us, simply multipy every local Coord
> vert by the CoordDef matrix to obtain the Graphic space vert.
>
> In OpenGL we simply multiplied the ModelView matrix by the
> CoordDef->matrix. In Performer we need to put a DCS above all the
> graphic objects created from a specific Coord.
>
>
> There is a One to One coorespondence between Coords and DCS that make
> this an easy solution. The problem is interactively moveing a Coord
> around in Graphic space. These demands selecting the DCS and
> recalculateing the DCS matrix based on wand input... not a problem. IT
> ALSO MEANS UPDATEING THE COORD OBJECT THAT CORESPONDS TO THE DCS. This
> is not such a big problem, we can specify a callback when the DCS is
> created. But what about if I bring a widget up on the screen and type in
> a new position for the CoordDef in the Graphic space? The CoordDef then
> needs to update the DCS. This demands that my CoordDef contain performer
> code... kinda sucks, but I can get over that... we can isolate it with
> #define USEING_PF.
>
>
> My question is (you were wondering when I would get to it wearn't you?)
> is:
>
> Isn't this sort of coupleing exactly what FCS,and pfEngines were
> designed for?

Engine-Flux chains were designed to support frame-accurate propagation of
results. In other words, consider the following chain:

       Flux_0 --> Engine --> Flux_1 in an FCS

If you modify Flux_0 at frame n, Flux_1 in the FCS node will not see the Engine
result until it hits frame n.

Do you need frame-accurate propagation ? If your matrix changes on GUI
request, you probably don't care.

If I managed to understand your application:
You can write a user-defined engine function that receives a new position
and calculates the new matrix. Your widget output has to write the new position
into Flux_0 (see pfFlux::getWritableData, pfFlux::writeComplete). I am not
sure this is buying you much - unless you care about a frame-accurate change
of the FCS matrix.

One additional point: Changing a DCS matrix causes a re-evaluation of the
bounding sphere/box of the nodes under and above it. Changing the FCS matrix
in Flux_1 doesn't cause any bounding volume re-evaluation. This could cause
wrong culling. You should modify the bounding volumes of relevant nodes yourself
or set them to large enough static bounding volumes.

-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 Tue Jan 12 1999 - 12:29:40 PST

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