Re: Non-linear transformation of pfGeoSet

New Message Reply Date view Thread view Subject view Author view

Rémi Arnaud (remi++at++remi.engr.sgi.com)
Thu, 19 Feb 1998 10:43:01 -0800 (PST)

Daniel Weiskopf wrote:
>
> Hello,
>
> I am a beginner at Performer programming. I have the following
>
> PROBLEM:
> For each frame, the vertices (coordinates and normal vectors)
> of the geometry (pfGeoSet) have to be transformed by a given
> non-linear mapping (for special relativistic visualization).
> To put it another way, this transformation can NOT be expressed
> by a normal 4x4 matrix. I'd like to achieve a frame-accurate
> behavior on a multiprocessing architecture.
>
> My ideas so far:
> The manual suggests four solutions for frame-accurate behavior:
> 1) passthrough data mechanism
> 2) frame-accurate pfSwitch
> 3) pfCycleBuffer
> 4) fluxed geosets/engines
> The transformation might be incorporated in application traversal.
>
> My question:
> Does anyone have any experience with a similar problem? In particular,
> I am interested in performance aspects/differences. Is it a good idea
> to put the transformation in the application traversal?

 If you have a lot of processing to do it may be worth considering to
 have a process to handle the computation (ie dedicate a cpu to do that).
 You can look at the radfly example in the friend of performer CD that
 recompute the colors of all the vertices using pfFlux and a separate
 process. You can use the same mechanism to recompute the vertices.

    _ / _ _
|_) _ ._ _ o /\ |_)|\ | /\ | || \
| \(/_| | || /--\| \| \|/--\|_||_/
                                           
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:56:48 PDT

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