30.4. Optimizing Everything Else

If you have determined that rendering is not your bottleneck, or if you have already optimized rendering as much as possible and a significant amount of time is still being spent doing something other than rendering, it’s time to look for other bottlenecks.

This section helps you find other bottlenecks, and suggests Open Inventor-specific things to look for by discussing the following:

Compression management is performed by the classes SoInput⁽^C++^|^Java^|^.NET⁾ and SoOutput⁽^C++^|^Java^|^.NET⁾. SoInput⁽^C++^|^Java^|^.NET⁾ supports compressed IV files even when the streaming mode is enabled, but the “read from buffer” feature does not support compression at this time. The SoOutput⁽^C++^|^Java^|^.NET⁾ class has been improved to compress the data on-the-fly. In order to write a compressed file a new file property can be set in any SoOutput⁽^C++^|^Java^|^.NET⁾ based object.

Example 30.1. Setting an SoOutput object for compressed output

C++

SoOutput fileOutputInterface;
fileOutputInterface.setFileProperty( SoOutput::CompressedZlib );

.NET

SoOutput fileOutputInterface = new SoOutput();
fileOutputInterface.SetFileProperty( SoOutput.FileProperties.CompressedZlib );

Java

SoOutput fileOutputInterface = new SoOutput();
fileOutputInterface.setFileProperty( SoOutput.FileProperties.CompressedZlib );

All applications that use SoInput⁽^C++^|^Java^|^.NET⁾ can read compressed files, including the SceneViewer, LargeModelViewer and IvTune.

Asynchronous reading

Open Inventor is now able to read a file and create the scene graph in parallel in order to accelerate large file loading. In the asynchronous loading mode, a separate thread reads the file in blocks and each time a new block of data is available the main thread creates the scene graph for that block while the reader thread loads the next block.

The number of buffers and the size of a buffer can be configured using the following environment variables:

OIV_STREAM_BUFFERS_NUMBER: Number of buffers to be used (4 by default).
OIV_STREAM_BUFFER_SIZE: Size of each buffer (1 MByte by default).

To enable or disable asynchronous loading use the new (optional) third parameter of SoInput⁽^C++^|^Java^|^.NET⁾::openFile, Example:

myInput->openFile( “myFile.iv”, FALSE, TRUE );

Progress status

Progress loading a file can now be monitored using the SoInput⁽^C++^|^Java^|^.NET⁾ class. To do so, the application must create its own class derived from SoInput⁽^C++^|^Java^|^.NET⁾ and implement the method:

SoInput::updateReadPercent( double readPercent )

This method is called periodically during a file read operation to update the progress. The readPercent parameter ranges from 0 to 100. This example shows how it could be done with a Qt progress bar:

C++

class MyInput : public SoInput
  {
  public:
    MyInput( QProgressBar* pgb ) : SoInput()
    {
      m_pgbPtr = pgb;
    }

    ~MyInput() {};

    virtual void updateReadPercent( double readPercentage )
    {
      m_pgbPtr->setValue( int(readPercentage) );
    }

  private:
    QProgressBar* m_pgbPtr;
  };

.NET

class MyInput : SoInput
{
  private ProgressBar myProgressBar;

  public MyInput(ProgressBar pgb) : base()
  {
    myProgressBar = pgb;
  }

  public virtual void updateReadPercent(double readPercentage)
  {
    myProgressBar.Value = (int)readPercentage;
  }
}

Java

class MyInput extends SoInput
{
  private JProgressBar myProgressBar;

  public MyInput(JProgressBar pgb)
  {
    super();
    myProgressBar = pgb;
  }

  public void updateReadPercent(double readPercentage)
  {
    myProgressBar.setValue((int)readPercentage);
  }
}

Optimizing Memory Usage

First, make sure your application isn’t running out of physical memory. If your application is swapping, try to reduce its memory usage as follows:

If you are using caching, avoid using PER_FACE or PER_FACE_INDEXED materials or normal bindings for SoTriangleStripSet⁽^C++^|^Java^|^.NET⁾ ,SoIndexedTriangleStripSet⁽^C++^|^Java^|^.NET⁾ , and SoQuadMesh⁽^C++^|^Java^|^.NET⁾nodes. FACE bindings force Open Inventor to break each triangle or quad into an individual triangle or quad, more than doubling the space the node takes in the render cache.
If you have SoBaseColor⁽^C++^|^Java^|^.NET⁾or SoMaterial⁽^C++^|^Java^|^.NET⁾nodes containing just diffuse colors, change them to SoPackedColor⁽^C++^|^Java^|^.NET⁾nodes, which use less memory.
Use instancing instead of duplicating geometry or properties wherever possible. Instancing makes your scene graph take up less memory and enables Open Inventor to build OpenGL display lists that are used more than once. This is especially important for SoTexture2⁽^C++^|^Java^|^.NET⁾nodes.

Looking at CPU Usage

If memory is not the problem, start by looking at “inclusive” CPU times for your procedures (inclusive times include time spent in that procedure and all procedures it calls; exclusive times are just the time spent in that procedure). Ignore the very highest level routines like main() or SoXt::mainLoop() ; look for Open Inventor beginTraversal() methods or for application routines that are taking a significant percentage of time. If a lot of time is spent in SoGLRenderAction::beginTraversal(), see Section 30.3, “ Optimizing Rendering” for information on improving rendering performance.

If your application is spending a lot of time in code written by you, you are on your own! The rest of this section describes Open Inventor routines that often show up on profile traces, describes what these routines do, and suggests ways of using them more efficiently.

Optimizing Action Construction and Set-Up

Open Inventor actions perform a lot of work the first time they are applied to a scene (subsequent traversals are very fast). Therefore, if your performance traces show a lot of time being spent inside an action’s constructor or the SoAction::setUpState()method, try to create an action once and reapply it instead of constructing a new action. For example, if you often compute the bounding boxes of some objects in the scene, keep an instance of an SoBoundingBoxAction around that is reused:

C++

static SoGetBoundingBoxAction *bbAction = NULL;
if (bbAction == NULL) bbAction = new SoGetBoundingBoxAction;
bbAction->apply(myScene);

.NET

static SoGetBoundingBoxAction bbAction = null;
...
if (bbAction == null) bbAction = new SoGetBoundingBoxAction(viewportRegion);
bbAction.Apply(myScene);

Java

static SoGetBoundingBoxAction bbAction = null;
...
if (bbAction == null) bbAction = new SoGetBoundingBoxAction(viewportRegion);
bbAction.apply(myScene);

instead of the much less efficient:

C++

SoGetBoundingBoxAction bbAction;
// inefficient if called a lot!
bbAction.apply(myScene);

.NET

Java

Decreasing Notification Overhead

Every time you change a field in the scene, Open Inventor performs a process called notification. A notification message travels up the scene graph to the node’s parents, scheduling sensors, causing caches to be destroyed, and marking any connections to engines or other fields as needing evaluation.

If your performance traces show a lot of time is being spent in a startNotify() method, try the following to decrease notification overhead:

If you are modifying several values in a multiple-valued field, use the setValues() methods or the startEditing() / finishEditing() methods instead of repeatedly calling the set1Value() method.

Build scenes from the bottom up. Set leaf nodes’ fields first, then add them to their parents, then add the parents to their parents, and so on. For example, do this:

C++

SoCube *myCube = new SoCube;
myCube->width = 10.0;
SoCylinder *myCylinder = new SoCylinder;
myCylinder->radius = 4.0;
SoSwitch *mySwitch = new SoSwitch;
mySwitch->whichChild = 0;
mySwitch->addChild(myCube);
mySwitch->addChild(myCylinder);
SoSeparator *root = new SoSeparator;
root->ref();
root->addChild(mySwitch);

.NET

SoCube myCube = new SoCube();
myCube.width.SetValue(10f);
SoCylinder myCylinder = new SoCylinder();
myCylinder.radius.SetValue(4f);
SoSwitch mySwitch = new SoSwitch();
mySwitch.whichChild.SetValue(0);
mySwitch.AddChild(myCube);
mySwitch.AddChild(myCylinder);
SoSeparator root = new SoSeparator();
root.AddChild(mySwitch);

Java

SoCube myCube = new SoCube();
myCube.width.setValue(10f);
SoCylinder myCylinder = new SoCylinder();
myCylinder.radius.setValue(4f);
SoSwitch mySwitch = new SoSwitch();
mySwitch.whichChild.setValue(0);
mySwitch.addChild(myCube);
mySwitch.addChild(myCylinder);
SoSeparator root = new SoSeparator();
root.addChild(mySwitch);

instead of the less efficient:

C++

SoSeparator *root = new SoSeparator;
root->ref();
SoSwitch *mySwitch = new SoSwitch;
root->addChild(mySwitch);
mySwitch->whichChild = 1;
SoCube *myCube = new SoCube;
mySwitch->addChild(myCube);
myCube->width = 4.0;
SoCylinder *myCylinder = new SoCylinder;
mySwitch->addChild(myCylinder);
myCylinder->radius = 4.0;

.NET

SoSeparator root = new SoSeparator();
SoSwitch mySwitch = new SoSwitch();
root.AddChild(mySwitch);
mySwitch.whichChild.SetValue(1);
SoCube myCube = new SoCube();
mySwitch.AddChild(myCube);
myCube.width.SetValue(4f);
SoCylinder myCylinder = new SoCylinder();
mySwitch.AddChild(myCylinder);
myCylinder.radius.SetValue(4f);

Java

SoSeparator root = new SoSeparator();
SoSwitch mySwitch = new SoSwitch();
root.addChild(mySwitch);
mySwitch.whichChild.setValue(1);
SoCube myCube = new SoCube();
mySwitch.addChild(myCube);
myCube.width.setValue(4f);
SoCylinder myCylinder = new SoCylinder();
mySwitch.addChild(myCylinder);
myCylinder.radius.setValue(4f);

Using many path sensors can cause notification to become slow, since an SoPathSensor⁽^C++^|^Java^|^.NET⁾is notified whenever any change happens underneath the head node of the SoPath⁽^C++^|^Java^|^.NET⁾monitored by the SoPathSensor⁽^C++^|^Java^|^.NET⁾ .
SoPath⁽^C++^|^Java^|^.NET⁾ itself does not have this problem in Open Inventor 2.X (and later, but did in Inventor 1.X).
Notification can be enabled or disabled on a per-node or per-engine basis. Beware that because caching, sensors, and connections rely on notification for proper operation, you must be very careful when using this feature. See the SoFieldContainer⁽^C++^|^Java^|^.NET⁾reference page for information on the enableNotify() method.


SoPath⁽^C++^\|^Java^\|^.NET⁾ itself does not have this problem in Open Inventor 2.X (and later, but did in Inventor 1.X).

Picking and Handling Events

If your application profiles show a lot of time is spent inside the methods SoHandleEventAction::beginTraversal()or SoPickAction::beginTraversal() , try the following to improve picking and/or event handling performance:

Insert SoPickStyle::UNPICKABLEnodes in your scene to turn off picking for objects that should never be picked (for example “dead” background graphics).
Insert SoPickStyle::BOUNDING_BOXnodes in your scene if you do not need detailed picking information. This helps most for complicated objects like SoText3⁽^C++^|^Java^|^.NET⁾or SoTriangleStripSetswith many triangles.
If you have objects with a lot (thousands) of polygons in them, break them up into several objects under different separators, grouping polygons that are close to each other. This allows SoSeparator⁽^C++^|^Java^|^.NET⁾ pick culling to quickly reject many of the triangles.
To speed up event handling, try to put active objects that respond to events toward the left and top of the scene graph. An SoHandleEventAction⁽^C++^|^Java^|^.NET⁾ends traversal as soon as a node reports that it has handled the event.
If you write your own event callback node, or implement a node that responds to events, be sure to use the grabEvents() method when appropriate. Because grabbing short-circuits traversal of the scene, it is a useful way to speed up event distribution.

Prev	Up	Next
30.3. Optimizing Rendering	Home	30.5. Optimizing for Large Amounts of Data