Package com.openinventor.inventor.simplifier

Large Model Visualization. Open Inventor and Large Model Visualization (LMV) The Solution for Large Model Visualization

In order to visualize graphics quickly, we have to be clever in choosing which primitives we feed to the graphics pipeline. The demand for increasingly complex 3D graphics models is growing faster than graphics workstation hardware can keep up. The only solution left is to find ways to represent models and scenes with fewer graphics primitives, and to send only the needed primitives to the graphics pipeline.

Since Open Inventor 2.4, there have been techniques to enhance large model visualization with view frustum culling and caching mechanisms and levels of detail. Starting with Open Inventor 2.5, we have gone further and added new techniques for visualization of large models and assemblies, as described below.

Geometry Simplification

The first algorithm Open Inventor includes is geometry simplification. The purpose of this algorithm is to simplify the rendered geometry of the model. After simplification, we have more options for the complexity of the model's representation and, therefore, we have more control over the rendering cost.

Open Inventor integrates mesh decimation through two components: a simplifier and a simplify action. The simplify action can be applied to a scene graph, or some part of it, to produce a simpler representation that will be used for subsequent redraws. A new node, SoLevelOfSimplification, has been added to group these representations and to keep track of their complexity levels, represented by a percentage of the original number of primitives.

Simplifiers

Objects derived from the virtual class SoSimplifier receive a set of triangles and return an Open Inventor node representing a simplified version of the original geometry. Thus one can ask for a simplified version of a triangle list containing 50% of the original number of triangles.

Open Inventor contains an SoDecimator object derived from SoSimplifier, which implements a geometry simplification algorithm. This algorithm uses iterative contractions of vertex pairs to simplify models. Simplifiers are used internally by simplify actions but can also be used by any application to generate a simplified node from a given list of triangles not stored in an Open Inventor node. The programmer can implement new simplification methods by deriving from SoSimplifier.

Simplify Actions

Open Inventor contains several simplify actions. Each action can be applied to a specific scene graph to create a simplified version of its geometry.

Each action's constructor receives an SoSimplifier which is used for simplifying the geometry. This simplifier can be an SoDecimator or any class derived from SoSimplifier by the application.

Several traversal methods are available:

  • SoGlobalSimplifyAction: traverses the scene graph and collects all the triangles in a single list. This list is then simplified and the result is stored in a new scene graph.
  • SoShapeSimplifyAction: traverses the scene graph and replaces every complex shape with its simplified version.
  • SoReorganizeAction: reorganizes the scene graph by grouping shapes with common properties, then groups these shapes in a single shape and runs the simplifier on it. If a simplifier is not provided it creates an SoIndexedTriangleStripSet from this shape. This action is similar to the ivfix utility program.

Each simplified sub-level can be stored in regular Separators or in WWWInline nodes. In this case, the urlName defines the full url to use for each WWWInline. For instance if urlName = "dir/file", the action will generate "dir/file_1.wrl","dir/file_2.wrl", and so on.

When a simplify action generates SoLevelOfSimplification nodes, the range field of each SoLevelOfSimplification node can be given globally in the range field of the simplify action. If the simplify action range field is not set, the simplify action computes it automatically for each SoLevelOfSimplification node. In this case, the sizeFactor field can be used to customize the range computation.

A minimum number of triangles can be set to stop the simplification when the object becomes too small.

Specifying 0% for the last level inserts an empty node in the scene graph. This allows you to completely remove objects that are too small or too far from the viewer.

The SoGlobalSimplifyAction provides two simplification strategies:

  • SIMPLIFY_GLOBALLY: all the triangles found in the scene graph are collected in a single object. Then this object is simplified.
  • SIMPLIFY_BY_SUBGROUP: triangles are collected until a material change or a separator is found.

The generateNormals flag can be used to force per-vertex normal computation during an SoGlobalSimplifyAction. When not set, objects may appear faceted instead of appearing smooth. Setting the addShapeHints flag to true tells Open Inventor to build normals at run-time.

By default the SoGlobalSimplifyAction collects all the triangles even if they are part of a simple shape (cube, cone, sphere, text3...). Setting the addShapeHints flag to false tells the action to collect triangles only if they belong to a complex shape.

The getSimplifiedSceneGraph() method returns the root of the new scene graph after applying the SoGlobalSimplifyAction.

Adaptive Viewing

Functionality was added to every viewer class in Open Inventor to be able to control the update rate, either through fixing the frames per second or the number of primitives rendered. For the viewer to be successful, there need to be nodes in the scene graph that can produce multiple levels of detail. What the adaptive viewers offer is a way for the user to set complexity goals that the dynamic nodes in the scene graph try to achieve.

Open Inventor implements adaptive viewing through a new action, SoGetPrimitiveCountAction, and a new element, DecimationPercentage. The GetPrimitiveCount action is used by the viewer to calculate the complexity of the scene graph by counting the number of triangles, points, lines, text, and images. It then can decide to render some lesser percentage of these primitives by setting the DecimationPercentage element. The viewer can fix the frame rate by timing each render and then adjusting the Decimation value to keep the frame rate within some desired range.

A new example demo program, the Large Model Viewer, has been developed to demonstrate this new functionality. With this program you can control the complexity of scenes output from the mesh decimation algorithm. In addition, you can control scenes that contain SoLOD nodes, and nodes that respond to the complexity element, such as Spheres, Cones, Cylinders, NURBS Curves and Surfaces, and 3D Text.

RenderList Node, ValueOrdering, OctreeOrdering

Large Model Viewing techniques require a spatial organization of shapes. Unfortunately, application scene graphs are often not organized spatially. The abstract node class, SoRenderList, has been developed to deal with this dilemma. This new node creates a flat, linear representation of the shapes within a hierarchical scene graph, which can then be traversed in any order or can be reorganized into a spatial scheme. This reorganization is transparent to the application, which receives the benefits of spatial organization without needing to change its logical organization of the scene graph.

In Open Inventor two organizational strategies have been implemented in the nodes SoValueOrdering and SoOctreeOrdering. Advanced programmers are given the ability to derive new nodes from the SoRenderList class to implement their own large model viewing techniques.

The SoValueOrdering node traverses the linear list of shapes generated by the SoRenderList node and determines the rendering value and cost of each shape. The rendering value is based on the object's approximate screen size and its cost is based on a count of the number of primitives the shape contains.

During each render traversal, the SoValueOrdering node determines how many primitives a shape deserves based on its rendering value. If the shape contains multiple levels of detail, then the SoValueOrdering node will choose the correct level of detail. However, this node also has two techniques that allow it to handle scenes that do not contain levels of detail: bounding box substitutes and drop culling.

If bounding box substitutes are enabled and the SoValueOrdering node calculates that the number of triangles that the object deserves is closer to 12 (the number of triangles in a bounding box) than to the minimum number of triangles the shape can draw, then the SoValueOrdering node will draw a bounding box instead of the shape. With drop culling enabled, a user can specify a size in pixels such that when the shape is less than this size, the shape is not rendered.

The typical scenario where this is useful is in CAD model assembly viewing, where all or most of the scene is visible, but lots of details may be so small that there is no point in drawing them until the user zooms in on them. Replacing such detail with its bounding box is adequate in many cases and does not have the disk and memory costs, along with the preprocessing time, associated with maintaining multiple levels of detail.

The SoOctreeOrdering node is more appropriate for use in walk-throughs or in other situations where the viewer is inside a large scene and much of the geometry is not visible from any given camera position. The linear list of shapes created by the SoRenderList node is processed and organized into an Octree which allows objects to be quickly dismissed if they fall out of the viewing frustum, for instance when they are behind or to the side of the viewer. The SoOctreeOrdering node also can replace with a bounding box groups of shapes that are too small, based on an approximate screen size.

The new Large Model Viewer demo program incorporates these two traversal ordering techniques as well. This allows an application developer to experiment with the different large model viewing techniques that Open Inventor offers and determine the best solution for his or her data.