SoFaceSet's composed
of independent triangles. The user can then rely on ivquicken
to glom as many of the triangles into strips as possible.
IndependentTriAction, the tesselation class is structured
much like a class derived from SoAction. It is not however, since
IndependentTriAction uses other actions (ie SoCallbackAction)
that would interfere with the traversal state maintained by
the SoAction class. Since the usage is the same, this should
amount to a semantic issue only.
At the heart of IndependentTriAction is the
SoCallbackAction::addTriangleCallback method. I also instrument
the source scene graph before and after each shape node with
callbacks that allow me to attach the new coordinates and normals
to the triangles. I name the new nodes to make deleting
the old shapes, normals, and coordinate nodes easy. After I process
all shapes in the graphs, I pare these out based on the name
of these nodes.
Although this program will work for all types of shapes, it doesn't
make a lot of sense to use it on shapes that already have efficient
representations. What I have observed is that the only shape that
is so slow to render as to demand tesselation is
the SoNurbsSurface class. The speedup for NURBS-infested
scene graphs is at least a factor of two or three at our current
release level (Irix 5.2 and Inventor 2.0). The tradeoff is that storing
the triangles will grow the resulting files by a factor of
several. This will directly affect loading time, and of course
exhaust more of your memory resources while viewing. Probably less
of a concern than raw rendering speed, but fair to mention nonetheless.
Caveats -
SoComplexity value is not always
heeded. Results vary, but this has since been fixed.
OR, ...