Michael Jones (mtj++at++babar)
Wed, 30 Mar 1994 08:43:20 -0800
:We have recently started using Performer 1.1 and are porting over code
:from our existing internally developed toolkit.
Any chance of upgrading to the lastest 1.2 version of IRIS Performer? It has
numerous facilities for building optimized database loaders, such as functions
to tesselate concave or complex polygons, form triangle meshes, and make
spatial-subdivision hierarchies from the resulting pfGeoSets. (It has a few
hundred other new features too...)
:We have constructed a "loadDgn" using the examples, which seems to
:work reasonable well. We have several questions however.
:
:1) Dgn files typically have lots of "shapes". The easiest thing to do
:is to create a new geometry and node for each of these. We get a bunch
:of geometries with pfGSetNumPrims set to 1. It seems that this
:approach creates lots and lots of nodes; in our first tests it seemed
:we have poor performance on such datasets.
Not unexpected. Triangle strips are desired, and geosets with tens of
primitives are best.
:One solution would be to collect the shapes of the different types
:(quads, or triangles) and then create a single geometry; however this
:is quite messy (and a LOT more work). Also culling won't work as nice
:if the orginally shapes were far apart. So what is the best approach?
Actually this is the EASY method with IRIS Performer 1.2 and the new
pfuBuilder() functions. You just allocate a pfuBuilder, add polygons one
at a time (each of which may have many sides, be concave, etc.) and
then call pfuMakeGSets() when you're done -- you'll be give a minimal
set of triangle strips of maximal length, as well as quads for the few
fragments you have left over. It's that easy and explained in detail in
the new Programming Guide.
If the resulting pfGeoSets are too big spatially, then use pfuBreakup to
reduce them to an efficient hierarchy.
:2) What happens if you don't set a pfGeoState for a pfGeoSet? Does it
:inherit the global state?
No. Having no pfGeoState is a kind of "don't care" mode. It's like
Bungee jumping without a cord. Since pfGeoStates inherit all modes
and attributes by default, the "use global state" solution is to make one
plain pfGeoState that's referenced by all the pfGeoSets you want to
have inherit the global state.
:3) This is the embarrassing one. We have lots of polygons that have
:greater that 4 vertices. Before we easily used gl to draw them. Now
:given drawing primitives that have < 5 vertices, do we have to
:decompose them into smaller polygons or are we missing something? If
:we have to decompose them, how do we do it?
You make a triangle strip that zig-zags the n-gon. For example, if you
had a 12-sided polygon, with vertices numbered as a clock face, you
could specify the triangle strip: 1, 2, 12, 3, 11, 4, 10, 5, 9, 6, 8, 7 which
makes for ten triangles, the same number which would have been
drawn by IrisGL when sent the 12-sided polygon.
Alternately, just give the 12 vertices to the pfuBuilder() and it will do
all the work for you. (Hint: use the pfuBuilder(), it's your friend)
:PS By the way, we have a lovely translator for taking dgn design files
:and turning them into polygons (at selectable resolutions). Is any one
:else doing the same? Here is a data file fragment of the output of the
:translator. We will convert it to binary in the future (always nice to
:debug in ascii :->).
--Be seeing you, mtj++at++sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:13 PDT