Michael Jones (mtj++at++isdn-celeste.corp.sgi.com)
Thu, 7 Nov 1996 06:58:31 -0800
: I have an inventor model with a single set of vertex and normal data in a
: vertexProperty node, and MANY IndexedTriangleStripSets that have references
: to the same vertexProperty node. When I load it into Performer I end up with
: a bunch of non-indexed tri-strips.
:
: In Performer, I would like to be able to retain a single set of vertex and
: normal data and indexing in the scene graph, but am at a loss about how to
: proceed. So far examination of the iv loader seems to indicate it might be
: an soDB function that is removing the indexed information and inserting
: actual vertex data (dereferencing the indices so to speak). Does anybody
: know if this is the case? If not, how the loader works in this regard?
You are exactly right. This loader works by loading the model into Inventor,
performing a traversal, and asking Inventor "what would you draw here?" at
each leaf node. The answer comes back via a point, line, and triangle call-
back that includes a material pointer. By the time you get there, all of
the indexing has been lost.
: Has anybody rewritten the loader to preserve indexed-ness?
Not here in the Performer group (we don't use Inventor in any way and it's
never come up as a question before to the best of my knowledge).
: Any opinions on what the best way to proceed is?
Modify the loader. In the traversal, when you get to a place where there
is a vertex/normal/etc. list, remember it (by pointer or copy). Then, when
you get to a geometry node, look to see if indexing is in force (does this
mean that you have to keep track of "binding" nodes too?) and if so, skip
the call to the Inventor "what-would-you-draw-here" callback and instead
do your own decoding of the primitives. The builder/geobuilder that is
in libpfdu does know about indexed geometry, as does Performer itself. You
will also need to keep track of separator nodes, and be able to properly
push/pop all of the state that you're tracking based on traversal order
as well as LOD/Switch behavior.
This will work correctly, but sure seems hard. Did this model spring to
life in Inventor form, or can you go back and get it in some easier to
deal with format (Obj, ...).
: BTW, the goal is to be able to morph the model and it seems to me that the
: most efficient way to do this is to operate on a single copy of the vertices
: rather that trying to search through the result of the iv-loader for multiple
: copies of the same vertices in the different non-indexed tri-strips. Anybody
: have a different take on this?
You are right about shared vertices being the most efficent from a how-much-
morphing-you-have-to-do standpoint.
If the object is "reasonable" perhaps you can just load it normally and then
write a traversal function to convert it from direct to indexed.
Be seeing you, Phone:415.933.1455 Fax:415.965.2658 MS:8U-590
Michael T. Jones Silicon Graphics, SSG--Advanced Graphics Division
mtj++at++sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311
120 Mario 64 Stars OpenGL/ImageVision/OpenInventor/Performer/Cosmo3D
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:54 PDT