[info-performer] New pfdOptimizeGraph functionality

Date view Thread view Subject view Author view

From: Stace Peterson (stacep++at++sgi.com)
Date: 12/16/2004 18:15:38


In Performer 3.2, we have implemented a set of libpfdu functions which
can be used for optimizing scene graphs for rendering. Since many
modeling packages will export geometry in non-optimal formats, or often
scenes can be created as the combination of many different sets of
geometry, it is often useful to have tools for taking scene graphs in
arbitrary formats, and greatly improving the performance of rendering
those scenes.

There are three general steps to the optimization pipeline introduced in
Performer 3.2. In order, these are pfdMergeGraph, pfdStripGraph, and
pfdSpatializeGraph.

The first step tries to compact a scene graph into a minimal number of
geometry objects (either pfGeoSets or pfGeoArrays) by combining those
which share state and attribute information. One interesting aspect of
the pipeline is that all three functions can output converted geometry
in both indexed or non-indexed formats, and can also force output
geometry to be either pfGeoSets or pfGeoArrays, or simply output in the
same format as input.

The second step is a bit more interesting, and performs per-primitive
optimizations. This includes restripping primitives, reordering the
primitives within the geometry to improve vertex cache reuse, and
merging strips to reduce the number of gl calls needed to render the
geometry, which can be valuable on machines in which bandwidth to the
graphics card is the bottleneck. Of note is that the pfdStripGraph
function, which performs these optimizations, is very flexible. It
takes a flags parameter, which can be used to enable or disable these
operations. Using these parameters, there are several ways to output
the geometry - a single merged triangle strip per geometry, or as
separate triangles. Together with the same output options discussed
above, these functions can be used as a simple geometry converter if
certain formats are easier to use for a given application.

The final step is the traditional spatialization. In Performer 3.2, we
have added some new functionality which allows for breaking up
geometries into octree structures, which allows the spatialization to
occur on a finer level than before (similar to pfdBreakup, but without
the constraints on use), and can result in improved culling.

Any of these functions can be used separately, or can be used in
pipeline to greatly improve rendering speed, especially for large
databases. Additionally, due to its flexibility, the pipeline can
produce many different outputs for the same input, critical since
different hardware favors different scene graph formats. For example,
some systems it might be critical to use large pfGeoArray objects due to
the overhead of rendering each one, whereas other systems favor much
smaller objects to get the maximum results out of culling.

We have also included a pseudo-loader called gopt which allows a user to
use the various functionality without writing any code. Please take a
look at the man pages for pfdOptimizeGraph and gopt for more detailed
information on their usage.

If any users have any questions, bugs, or suggestions about improvements
to the optimization pipeline, please send email to either
info-performer, performer-feedback, or me (stacep), all at sgi.com.

Thanks,
Stace Peterson

-- 
------------------------------------------------------------------
Stace Peterson                                      stacep++at++sgi.com
Silicon Graphics, Inc.                              (650) 933-2323


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Thu Dec 16 2004 - 18:15:49 PST