The caching process begins with the separator group, as follows:

The nodes under the separator group may inherit values from nodes that appear before the separator group in the graph. For example, materials, coordinates, texture coordinates, complexity nodes, normals, and bindings tend to be used by each shape. If these values change, the cache needs to change. (Note that if a texture outside the cache changes, the cache is still valid because the shape does not send the texture calls to OpenGL. The texture is sent directly to OpenGL when the SoTexture2 SoTexture2 SoTexture2 node is traversed.)

Be aware that these changes also invalidate the cache:

Inventor is conservative in determining whether the current cache is valid (that is, caches may be invalidated and rebuilt even if inherited values have not changed).

Figure 9.24, “ Caching a Shape ” shows a scene graph with a transform node whose values are changing frequently and a cube. In this case, turn on caching at the separator above the cube so that the changing transform values do not invalidate the cache.

Figure 9.24.  Caching a Shape

Figure 9.25, “ Caching a Shape along with a Changing Property Node ” shows a scene graph with a complexity node whose values are changing frequently and a cube. Here, you would include both the property node and the shape in the same cache, since the shape always uses the property node when it is rendered.

Figure 9.25.  Caching a Shape along with a Changing Property Node

Render caches can consume a great deal of memory, but they are very useful for speeding up rendering. Using the AUTO (default) value for render caching allows Inventor to determine whether creating a render cache will save time.

Bounding-box caching is relatively inexpensive. Inventor uses bounding- box caching to speed up picking. If bounding-box caching is on and the user picks part of the graph that contains a separator group, the separator group can first check to see if the bounding box is picked. If not, it knows nothing under it is picked and does not need to traverse the subgraph.

The SoSFBool SoSFBool SoSFBool field boundingBoxIgnoring has been added in some nodes in order to ignore the bounding box of the specified nodes. The value indicates whether the bounding box is ignored or not. It can be useful to ignore the bounding box for annotation geometry (for example color bars and legends) that should not be considered by the viewer’s “viewAll” operation. This field can also be used to suppress computation of the bounding box for very large or frequently modified geometry. However ignoring the bounding box of actual scene geometry can cause problems, for example with automatic adjustment of clip planes in the viewer. For scene geometry we recommend using the SoBBox SoBBox SoBBox node to specify a precomputed bounding box.

An effect similar to ignoring the bounding box could previously be accomplished using an SoResetTransform SoResetTransform SoResetTransform node to reset the bounding box. Using the boundingBoxIgnoring field or SoBBox SoBBox SoBBox node is more efficient because it avoids computing the bounding box.

The following nodes and all inherited nodes contain this field:

This node allows the application to specify a bounding box for a portion of the scene graph. The main goal of this node is to avoid computing the bounding box when we already know it. Computing the bounding box for a large geometry (e.g. 1 million+ triangles) can be time consuming, especially if the geometry is changing, for example driven by an animation.

Figure 9.26. Scene graph with a SoBBox node

In this example the bounding box is computed in each node up to the node SoBBox SoBBox SoBBox . It is not computed for the nodes placed after the SoBBox SoBBox SoBBox node.

The mode field has three possible values:

This node is used in two demos:

$OIVHOME/src/Inventor/examples/Features/BufferObjects/AnimatedShape

$OIVHOME/src/Inventor/examples/Features/BufferObjects/SoBufferedShape

The first demo renders an animated textured shape. There is no need to compute the bounding box for each animation step because the formula is based on an amplified sin function and the bounding box is defined by the limits of the formula. The bounding box node is added just before the shape so the bounding box action will not compute a bounding box for the shape.

The second demo renders a huge geometry using an SoBufferedShape SoBufferedShape SoBufferedShape node. Computing the bounding box of this shape takes a long time because the geometry is stored directly on the graphic card. Therefore computing the bounding box requires uploading the data to system memory before computing the bounding box. But we can precompute the bounding box for this shape and set it using an SoBBox SoBBox SoBBox node. Changing the scale of the geometry triggers a scene graph traversal for the bounding box, but we can apply the same scale to the bounding box, there is no need to compute it using the geometry.

See the section called “Buffered Shape” for more information about SoBufferedShape SoBufferedShape SoBufferedShape .

To use fast editing, there are two steps:

We recommend using the EACH_FRAME flag when manipulating a very large main scene graph. In this case, the time used for saving buffers is insignificant compared to the time required to draw the scene. EACH_FRAME is recommended as well when the fast editing sub-scene graph is modified frequently. User interactivity is better with the fast edit graph even if the global scene frame rate may slow down.

It would be better to use WHEN_NEEDED when the fast editing sub-scene graph changes occur very rarely. In this case, you will have full performance when rendering the main scene graph because no buffers are saved.

The fast editing feature is illustrated by the example in the $OIVHOME/src/Inventor/examples/features/fastEditing directory.

Large Model Viewing techniques require a spatial organization of shapes. Unfortunately, application scene graphs are often not organized spatially. The abstract node class, SoRenderList SoRenderList SoRenderList , has been developed to deal with this issue. 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, several strategies have been implemented in the nodes SoValueOrdering, SoOctreeOrdering, and SoOcclusionCulling. Advanced programmers can derive new nodes from the SoRenderList SoRenderList 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 SoValueOrdering 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.

SoValueOrdering SoValueOrdering SoValueOrdering has the following fields:

SoValueOrdering *valueOrdering = new SoValueOrdering;
valueOrdering->ref();

// This is the default value.
valueOrdering->dropCulling = TRUE;

// When the size of a shape is less than 40 pixels, the shape is not rendered.
valueOrdering->dropScreenArea = 40;
valueOrdering->boundingBoxSubstitutes = FALSE;
valueOrdering->decimateSubstitutes = FALSE;
valueOrdering->lowValueCulling = FALSE;
valueOrdering->adjustDecimation = FALSE;

// Read the whole file into the database
SoSeparator *root = SoDB::readAll(&mySceneInput);
if (root == NULL) return;
valueOrdering->addChild(root);
            

SoValueOrdering valueOrdering = new SoValueOrdering();

// This is the default value.
valueOrdering.dropCulling.SetValue(true);

// When the size of a shape is less than 40 pixels, the shape is not rendered.
valueOrdering.dropScreenArea.Value = 40;
valueOrdering.boundingBoxSubstitutes.Value = false;
valueOrdering.decimateSubstitutes.Value = false;
valueOrdering.lowValueCulling.Value = false;
valueOrdering.adjustDecimation.Value = false;

// Read the whole file into the database
SoSeparator root = SoDB.ReadAll(mySceneInput);
if (root == null) return;
valueOrdering.AddChild(root);
          

SoValueOrdering valueOrdering = new SoValueOrdering();

// This is the default value.
valueOrdering.dropCulling.setValue(true);

// When the size of a shape is less than 40 pixels, the shape is not rendered.
valueOrdering.dropScreenArea.setValue(40);
valueOrdering.boundingBoxSubstitutes.setValue(false);
valueOrdering.decimateSubstitutes.setValue(false);
valueOrdering.lowValueCulling.setValue(false);
valueOrdering.adjustDecimation.setValue(false);

// Read the whole file into the database
SoSeparator root = SoDB.readAll(mySceneInput);
if (root == null) return;
valueOrdering.addChild(root);
          

Figure 9.28.  SoOctreeOrdering applied to a bird model

The SoOctreeOrdering SoOctreeOrdering SoOctreeOrdering node is a way to optimize performance in immersive applications. It is also a way to improve view frustum culling for the ScaleViz multipipe viewers as well as the “classical” Open Inventor viewers (Examiner Viewer, etc.).

Basics

The linear list of shapes created by the SoRenderList SoRenderList SoRenderList node is processed and organized into an octree. The octree is constructed by a recursive spatial decomposition of the scene (see Figure 9.28, “ SoOctreeOrdering applied to a bird model”).

The root of the tree data structure represents the bounding box of the entire scene. This bounding box is split into eight equal octants which represent the eight children of the root. If an octant is empty, the node referencing this octant has no children. If an octant contains any objects (see Figure 9.29, “ The SoOctreeOrdering data structure”), the node referencing this octant has eight children referencing the eight new octants.

The subdivision process stops according to a per-object stop criterion based on the greatest bounding box value of this object. The smaller an object is, the deeper it is in the octree.

Figure 9.29.  The SoOctreeOrdering data structure

Using an octree data structure is very efficient for view culling because if an octant is culled, all of the objects in this octant are automatically culled. This makes it very helpful 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. Moreover, the SoOctreeOrdering SoOctreeOrdering SoOctreeOrdering node can also use bounding box substitutes for groups of shapes that are too small to display based on an approximate screen size.

Hardware considerations

As explained above, if you run your application in multithreaded mode, work can be divided between the threads, thus improving wireframe rendering performance. However, there are also some limitations.

For example, on a single processor machine, running a multithread application means there are several threads. However, since there is still only one processor, each thread is handled by this single processor, one at a time. Every thread is allocated a very small amount of time to run on the CPU. There is no real parallel execution. Because dividing work between two threads on a single processor machine is essentially the same (as far as time is concerned) as giving all the work to one thread, you may not see improved performance on a single processor machine.

SoOctreeOrdering SoOctreeOrdering SoOctreeOrdering has the following fields:

dropCulling (SoSFBool)	Enables/disables culling of shapes that would be smaller on the screen than the dropScreenArea threshold.
dropScreenArea (SoSFUint32)	Sets threshold in pixels for drop culling and bounding box substitutes.
boundingBoxSubstitutes (SoSFBool)	Enables/disables use of bounding boxes for octree cells (containing shapes) that would be smaller on the screen than the dropScreenArea threshold.
useMovingQueue (SoSFBool)	Sets how this node should handle moving render objects. If TRUE, then moving objects are kept in a separate render list, and are not sorted into the octree, meaning that they will not be drop culled. If FALSE, moving objects will be sorted into the octree after each motion, taking more time, but enabling drop and view frustum culling for the moving objects.
adjustDecimation (SoSFBool)	If TRUE, the octree will alter the decimation percentage for objects depending on how large they are in the view. This causes objects closer to the camera to be displayed with more detail than objects further away.

SoOctreeOrdering SoOctreeOrdering SoOctreeOrdering has the following methods:

void setOctreeDrawing(SbBool enable)	Allows you to visualize the octree and see how it organizes your scene.
SbBool isOctreeDrawing ()	Returns TRUE if drawing is on, else returns FALSE.
void SoOctreeOrdering::setReportCB(SoReportCB *func, void *userData)	You can set a callback for your octree to find out how many objects were rendered by each thread and other details. Your callback must have the following type: void myCallback (SoOctreeOrdering *node, int numObjTotal, int numObjRendered, void *userData)

	If you set the environment variable OIV_DRAW_OCTREEto 1, the octree will draw itself each time you use it.

Example 9.2. How to use the SoOctreeOrdering node

SoOctreeOrdering *octreeOrdering = new SoOctreeOrdering();
octreeOrdering->ref();

// This is the default value.
octreeOrdering->dropCulling = TRUE;

// When the size of a shape is less than 40 pixels,
// the shape is not rendered.
octreeOrdering->dropScreenArea = 40;

// Read the whole file into the database
SoSeparator *root = SoDB::readAll(&mySceneInput);
if (root == NULL)
{ 
  fprintf(stderr, "Problem reading file\n"); 
  return;
}

octreeOrdering->addChild(root);
                

SoOctreeOrdering octreeOrdering = new SoOctreeOrdering();

// This is the default value.
octreeOrdering.dropCulling.Value = true;

// When the size of a shape is less than 40 pixels,
// the shape is not rendered.
octreeOrdering.dropScreenArea.Value = 40;

// Read the whole file into the database
SoSeparator root = SoDB.ReadAll(mySceneInput);
if (root == null)
{ 
  Console.WriteLine("Problem reading file");
  return;
}

octreeOrdering.AddChild(root);
              

SoOctreeOrdering octreeOrdering = new SoOctreeOrdering();

// This is the default value.
octreeOrdering.dropCulling.setValue(true);

// When the size of a shape is less than 40 pixels,
// the shape is not rendered.
octreeOrdering.dropScreenArea.setValue(40);

// Read the whole file into the database
SoSeparator root = SoDB.readAll(mySceneInput);
if (root == null)
{ 
  System.err.println("Problem reading file");
  return;
}

octreeOrdering.addChild(root);

Open Inventor provides several culling operations, e.g., back face culling and view frustum culling, that remove faces or objects that do not need to be rendered. However, none of these prevent occluded objects (an object entirely behind another one, which means that the object will not contribute to the final image) from being drawn. An occluded object needlessly increases depth complexity. The SoOcclusionCulling SoOcclusionCulling SoOcclusionCulling node culls those objects.

How does it work?

The occlusion test is performed with an OpenGL-based occlusion test. The node uses its render list, sorts the objects from front to back, draws the first one, and then asks the board if the second closest object is occluded by the first. The object is occluded if none of its bounding box’s pixels would have been written in the Z-buffer, which means the first object entirely hides the second one (every second object’s pixels are located in the same array than first object’s pixels which all have a greater z value). If it is not occluded, then the object is drawn and becomes an occluder for the next object (more pixels are in the Z-buffer) and so on.

	Occlusion culling requires the HP_OCCLUSION_TEST. If this extension is not available, SoOcclusionCulling SoOcclusionCulling SoOcclusionCulling behaves the same as an SoSeparator SoSeparator SoSeparator .

SoOcclusionCulling *occlusion = new SoOcclusionCulling;
occlusion->ref();

SoSeparator *myScene = SoDB::readAll(&mySceneInput);

occlusion->addChild(myScene);
            

SoOcclusionCulling occlusion = new SoOcclusionCulling();

SoSeparator myScene = SoDB.ReadAll(mySceneInput);

occlusion.AddChild(myScene);
          

SoOcclusionCulling occlusion = new SoOcclusionCulling();

SoSeparator myScene = SoDB.readAll(mySceneInput);

occlusion.addChild(myScene);

SoOctreeOrdering *octree = new SoOctreeOrdering;
octree->ref();

SoOcclusionCulling *occlusion = new SoOcclusionCulling;
occlusion->ref();
occlusion->isHead.setValue(FALSE);

SoSeparator *myScene = SoDB::readAll(&mySceneInput);

octree->addChild(occlusion);
occlusion->addChild(myScene);
            

SoOctreeOrdering octree = new SoOctreeOrdering();

SoOcclusionCulling occlusion = new SoOcclusionCulling();
occlusion.isHead.Value = false;

SoSeparator myScene = SoDB.ReadAll(mySceneInput);

octree.AddChild(occlusion);
occlusion.AddChild(myScene);
          

SoOctreeOrdering octree = new SoOctreeOrdering();

SoOcclusionCulling occlusion = new SoOcclusionCulling();
occlusion.isHead.setValue(false);

SoSeparator myScene = SoDB.readAll(mySceneInput);

octree.addChild(occlusion);
occlusion.addChild(myScene);