Re: rebuilding a scene graph

New Message Reply Date view Thread view Subject view Author view

From: Yair Kurzion (yair++at++polygon.engr.sgi.com)
Date: 10/04/2001 10:55:51


Hello Jason !

By default, Performer uses multiple processes for processing the scene graph.
These processes run as a pipeline: When your application works on frame N,
a Performer CULL process works on frame (N-1), and a DRAW process works on
frame (N-2).

All your scene graph internal nodes (not pfGeoSets) are multi-buffered. So,
each phase in the pipeline owns a copy of all the internal nodes.
Plain pfGeoSets are not multi-buffered so if you change them in your application
program, your changes interfere with other pipeline stages (and may crash your
program).

You can create multi-buffered pfGeoSets explicitly by using a pfFlux. There
are multiple short sample programs for using pfFluxes under
    /usr/share/Performer/src/pguide/libpf
I suggest that you take a look at:
    /usr/share/Performer/src/pguide/libpf/C++/fluxed_gset.C
and read the man pages on pfFlux and on pfFluxedGSetInit. Also, the Performer
programmer's guide contains a chapter on pfFluxes called `Dynamic Data'.

-yair

> im generating the geosets on the fly, and on occasion, i need to
> rebuild the
> scene graph given a new mesh density. the issue is that im getting a
> segfault
> in various places within the app process.
>
> in order to regenerate the scene graph, i setScene( NULL ) on the
> channel,
> remove the geoset from the geode, pfFree the vertex, tex coord &
> index arrays,
> pfMalloc them to their new sizes, re calc them, and stuff them back
> in the
> geoset. i then reattach everthing. ( im currently working with
> meshs of
> quads of N x N size )
>
> i can remesh the geosets as much as i want ( which includes the
> destruction &
> reallocation of the various arrays ) as long as the _sizes_ of the
> arrays do not change.
> when they do change, i will get the segfault but only for some
> sizes, and not
> others. it seems to like odd sizes, and crashes on even sizes for
> some reason.
> this is just what ive noticed so far.
>
> if anyone has any insight or if anything sounds amiss, please
> advise.
>
> thx.
>
> ~J
>
> // =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Jason M. Coposky, 3D Software Engineer
> jasonc++at++elumens.com
> // =-=-=-=-=-=-=-=-=-=
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
> -----------------------------------------------------------------------
>

-- 
\_________  \_____  \__    \__  \_____        
\_________  \_____   \__   \__  \_____         Yair Kurzion
       \__     \__   \____\__      \__         yair++at++sgi.com
       \__          \__  \__                  (650) 933-6502
       \__          \__   \__          
       \__          \__    \__             


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Thu Oct 04 2001 - 10:55:55 PDT

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