Open Inventor FAQs - Performance

Do you have any suggestions for measuring Open Inventor performance?

The ivShapeBenchmark utility program can be used to create interactively complex shapes and to measure rendering speed. To get an approximate idea of performance, you can also run the Large Model Viewer, which displays the frame rate, and also allows you to try various LMV features to see if they benefit your geometry.

Spinning an object in a viewer is definitely not the best way to measure the top performance of Inventor. This is because the "spin" behavior of ExaminerViewer runs off a timer which adds some overhead. Also, all viewers perform (optional) overhead for each frame, including headlight adjust and clip plane adjust.

Also, you should make sure that the vertical synchronization of your graphic board is turned off. Otherwise you will never get more than 60 frames per second corresponding to the refresh rate of the screen.

What you want to do (roughly speaking) is:

f or i=0,n

and get the time before and the time after rendering. Subtract the times to get the time spent rendering.

We supply ivperf, a utility program that renders an Inventor file and provides a variety of timing statistics. We supply the source too (in src\Inventor\tools\ivperf) so you can see exactly what the program is doing, and so that you can make modifications if you see fit.

For additional information on ivperf, see its documentation and also the Performance tips topic (or the "Optimizing Applications" chapter), which provides general performance tuning info as well.

[Win32] How can I tell if I am getting OpenGL acceleration in my Open Inventor application? (I'm running in the Win32 environment.)

The following quick experiment will give you a clue:

Run the SceneViewer (or other viewer of your choice), read in some geometry (something complex enough to provide a reasonable challenge), make the window small, and spin the object. See how fast it goes.

Now, maximize the window, and spin the object again. If you see roughly the same performance, then you are probably getting HW acceleration. If the performance is noticeably slower, you are probably not getting acceleration.

Here's how you can be sure:

Run the oglinfo program that is supplied in the contrib directory of the Open Inventor SDK. It will print out information about the pixel formats available on your system, including which ones are accelerated. (Note that the accelerated pixel formats may vary depending on the resolution and number of colors.)

Set environment variable OIV_DEBUG_PIXEL_FORMAT=1, run your program (built with the debug target). Look at the resulting file named pixel.txt. It will tell you what pixel format is being used. Check the oglinfo output to see if that pixel format is accelerated.

Does Open Inventor for Java perform as well as Open Inventor for C++?

The core of Open Inventor for Java is written in C++. The time required to copy the data from Java to C++ is often very small. Furthermore, the Java virtual machine proivde very good performances for on the fly compilation. All of the scene graph traversal and rendering is done using C++ code, so there is no difference in rendering performance. 

Instead of exposing the whole scene to SoRayPickAction, I am going to make only the shape I want it to pick available while making the rest of nodes unpickable. Will this improve picking performance?

That may or not help. It is hard to improve on Open Inventor's picking. What it does is cache the bounding boxes of the geometry at the separator node above the geometry, so if the scene graph is spatially well-behaved, i.e., the objects are spread out and not overlapping, the pick action does not have to traverse under a separator where there could not possibly be a hit. Making nodes unpickable is not a performance-enhancing feature, but rather solves the problem of overlapping geometry by limiting the pickable objects to those of interest.

In your case where you apparently already know what portion of the scene graph contains the objects you want picked, you can use the apply method of SoRayPickAction to specify a path for the pick to traverse, thereby limiting traversal to that sub-graph of the entire scene graph.

The best optimization for picking is to organize your scene graph according to the location of the objects in 3D space. This allows bounding box culling to be most effective. Of course this often conflicts with other requirements for organizing your scene graph ;-)

It seems to take a long time to display my scene graph that uses a lot of texture images.

Use power-of-2 texture dimensions

As you may know, OpenGL only handles textures that have dimensions that are powers of 2. If you provide texture images that have dimensions that are not powers of two, Open Inventor will automatically scale them up to the nearest power of 2. This is a convenience feature, but can be time consuming because of the computations that are involved. We recommend that users provide textures that are already dimensioned in powers of 2 in order to improve performance. However, note that scaling is only done once, so this does not affect overall frame rate, only the time to display the initial image.

If you are particularly concerned about keeping the image quality as high as possible, don't scale the image, but rather add (any color) pixels to the top and right to make the image size a power of 2. Then use texture coordinates to tell Open Inventor to use only the portion of the image that contains the "real" texture pixels.

For example:

  1. Suppose your image is 400 x 400.
  2. Add 112 pixels (of any color) on the top and right to make an image that is 512 x 512.
  3. When you map this texture to your object, specify texture coordinates such that only the pixels from 1-400 are mapped onto your object. For a rectangular polygon, the texture coordinates, starting at the lower left, counterclockwise, would be (0,0), (.78125,0), (.78125,.78125), (0,.78125).

This produces better quality because there is one less scale operation to potentially cause a loss of quality.

Use SoExtTexture2 Node

This node was specifically designed for handling texture memory and system memory efficiently.

  • It doesn't load the texture image into system memory until the node is traversed. Depending on the scene graph, this may significantly reduce the use of system memory, e.g., if the scene has lots of LODs containing textures. The textures will only be loaded for nodes that are actually displayed (i.e., only the active LOD children). On the other hand, when the scene graph is first traversed there may be a small delay while the textures are being loaded.
  • To reduce the use of texture memory (by approximately a factor of 4), use the useTexturePalette method to request the image be converted to a 256-color paletted image. This feature is available only if the driver supports the GL_EXT_paletted_texture or GL_EXT_texture_color_table extension.

See the SoExtTexture2 write-up in the help file for further details

Tip: Supply normals for your geometry (rather than letting the normals be computed by Open Inventor). (Or...why does it take so long to add a large surface to the scene graph?)

It's a very convenient feature of Open Inventor that you are not required to supply normals (vertex normals and/or face normals) for the geometry in your scene graph. However, there is a price to be paid for this convenience. You are hit with the cost of the computation as well as a substantial increase in memory usage. The computation time may not be noticeable for small and medium size geometry, but may be substantial for large surfaces.

If it's practical for you to supply your own normals, and performance is important, we suggest that you do so.

A question that this raises is:

Is there a way to "capture" the normals computed by Open Inventor and save them for future use?

Yes! See the "General" section of this FAQ for the answer to this question.