Large Model

Large Model Visualization. More...

Classes
class	SoGlobalSimplifyAction
	Traverses the scene graph and collects all the triangles in a single list. More...
class	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. More...
class	SoShapeSimplifyAction
	Simplify action that replaces shapes within a scene graph with versions that contain fewer triangles. More...
class	SoLevelOfSimplification
	Level-of-detail switching node designed for grouping simplified versions of the same shape. More...
class	SoDecimator
	Encapsulates an algorithm for simplifying shapes through mesh decimation. More...
class	SoSimplifier
	Abstract base class for objects that encapsulate simplification algorithms. More...

Detailed Description

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.