Chapter 4. New Features

This chapter describes the major new features that distinguish Open Inventor 2.1 from Open Inventor 2.0. It discusses the following topics:

Version-Related Changes

This section discusses various issues directly related to the version change:

File Version

The file version has been updated to 2.1; files written out with Open Inventor 2.1 have the file header #Inventor V2.1 ascii or #Inventor V2.1 binary. Inventor 2.1 programs are still able to read 2.0 and 1.0 files. Older programs cannot read 2.1 files; the files must be converted to the appropriate version with the ivdowngrade program discussed in “File Downgrade Utility”.

Inventor Revision Symbols

C preprocessor symbols SO_VERSION and SO_VERSION_REVISION have been added to Inventor/SbBasic.h to identify the revision of Inventor being compiled against:

  • SO_VERSION is the major version number (for Inventor 2.1, “2”)

  • SO_VERSION_REVISION is the minor revision number (for Inventor 2.1, “1”)

If you use parts of the Inventor API that changed between revisions, you can use these symbols to conditionally compile (#ifdef) your code if you want the same source to compile against multiple versions of Inventor.

DSO Directories and Versions

To avoid problems with incompatible code, the places Inventor searches for DSOs (dynamic shared objects) implementing new nodes has been changed. Inventor 2.1 searches in the following order:

LD_LIBRARY_PATH:/usr/lib:/lib              (normal rld rules)
.:/usr/local/lib/InventorDSO:/usr/lib/InventorDSO       (new)

If you're running a setuid or setgid program, or if running as root, the order is:

/usr/lib:/lib                              (normal rld rules)
/usr/lib/InventorDSO                                    (new)

The /usr/lib/Inventor and /usr/local/lib/Inventor directories were used for Inventor 2.0. For example, if you created a new node of type NewNode and created DSOs for both Inventor 2.0 and Inventor 2.1, you could put the Inventor 2.0 in the /usr/local/lib/Inventor/ directory and put the Inventor 2.1 in the /usr/local/lib/InventorDSO/ directory.

To avoid future problems with incompatible DSOs, Inventor 2.1 and future releases of Inventor will search for DSOs that are given the same version number as the Inventor libraries. For Inventor 2.1, DSOs for new nodes and engines must be tagged with version “sgi3.0”. This is accomplished by adding the flag -set_version “sgi3.0” when creating the DSO. See the reference page for ld for more information on DSO versioning, and the Inventor release notes for information on creating DSOs for new Inventor classes.

File Reading and Writing

This section explains changes related to file reading and writing.

Support for VRML Files

The SoDB read methods now also read files with the VRML 1.0 header.

User-Defined File Headers

The SoDB class now includes methods for registering your own file headers. This is useful, for example, if you have an application that supports a superset of the Inventor file format, and you want to use the Inventor file reading mechanism to parse the file. Similarly, you can specify your own header for output files using methods of the SoOutput class. See the reference pages for more details.


You can now specify the precision Inventor uses when writing floating point numbers in the ASCII file format. The new setFloatPrecision() method on SoOutput takes one argument, an integer specifying the desired precision. For example, a precision of 2 limits the output of floating point numbers to 2 significant digits.

New Nodes

This section discusses new nodes that don't result in incompatible API changes or scene appearance changes. It provides information about:

SoVertexProperty Node

A new node class, SoVertexProperty, has been added. The SoVertexProperty node is a performance feature of Inventor 2.1; it does not add functionality. Open Inventor applications that use this node may show a speed improvement, particularly for non-cached rendering.


The SoVertexProperty node allows you to specify in one node all the vertex data for a vertex-based shape (that is, any shape derived from SoVertexShape). This is more efficient than inheriting the data from several different nodes. An SoVertexProperty node has the following fields:


the coordinates, specified as SoMFVec3f


the normal vectors, specified as SoMFVec3f


the normal binding, specified as SoSFEnum


the packed color and alpha values, specified as SoMFUInt32


the material binding, specified as SoSFEnum


the texture coordinates, specified as SoMFVec2f

When the SoVertexProperty node is used, it replaces the SoCoordinate3, SoNormal, SoNormalBinding, SoTextureCoordinate2, SoMaterial (when used to specify multiple colors), and SoMaterialBinding nodes.


The vertex, normal, orderedRGBA, and texCoord fields are all NULL by default. If any of these fields are not specified, the shape inherits the values from other nodes in the scene.

The default normalBinding is PER_VERTEX, and the default materialBinding is OVERALL. However, the normalBinding is ignored if the normal field is not used. Similarly, the materialBinding field is ignored if the orderedRGBA field is not used.


The SoVertexProperty node can be used by the shape in either of two ways:

  • The SoVertexProperty node is placed in the scene and inherited by the shape node.

    This is the same model used for inheritance for other property nodes in Inventor.

  • The vertex-based shapes have a new SoSFNode field, vertexProperty, that allows you to directly include the SoVertexProperty node in the shape.

    This is a significant change from the inheritance model used for other properties. The properties specified in the node apply only to the shape in which it was included; they do not affect any subsequent shapes.

Performance Considerations

For maximum performance, observe the following rules of thumb:

  • Use the SoVertexProperty node to specify properties for the vertex-based shapes if you have a scene that cannot be cached.

  • Use the vertexProperty field of the shapes to directly include the SoVertexProperty node; don't place the SoVertexProperty node in the scene and inherit by the shape node.

  • Use the fields in the SoVertexProperty node to specify all the data you need for a shape; don't mix and match data from the SoVertexProperty node and inherited values from other nodes.

  • Specify normals and texture coordinates if you need them; don't rely on the automatic generation, which is expensive if the scene cannot be cached.

  • Don't use the convenience feature of specifying the number of vertices as -1 (that is, use all remaining vertices); specifying the actual number is more efficient.

SoLOD Node

Open Inventor 2.1 has an improved version of the node that provides switching between different levels of detail in the scene. The new node is named SoLOD, to avoid conflict with the old node, SoLevelOfDetail. For compatibility, the old node is still supported.

The new SoLOD node switches between different levels, depending on the distance of the object from the eye. The old SoLevelOfDetail node used screen area to determine when to switch levels. Using distance is much faster than using screen area.

SoLocateHighlight Node

SoLocateHighlight is a new, special separator that performs locate highlighting. When the window cursor is over the contents of this separator, it efficiently redraws itself in a different color. This is useful for indicating hot spots in a scene. See the reference page for more details.

VRML Nodes

The Open Inventor file format formed the basis for the Virtual Reality Modeling Language (VRML), the industry-standard, platform-independent file format for 3D graphics on the Internet. VRML 1.0 includes a few nodes that were not in Inventor 2.0; these nodes have been added to Open Inventor 2.1, which is now a superset of VRML 1.0. The new nodes in Open Inventor 2.1 are:

  • SoWWWAnchor

  • SoWWWInline

  • SoAsciiText

  • SoFontStyle

See the reference pages for more information on these nodes. For more information on VRML, visit the World Wide Web page at

New Fields

This section looks at two new fields, “The “fields” Field” and “The “isA” Field.”

The “fields” Field

Inventor writes custom nodes with an extra field named fields that lists the names of all fields in the node along with their types. Inventor 2.0 files could not be read if a fields field was included in a node that was a standard part of the library. To be fully compliant with VRML 1.0, Inventor 2.1 files now support a fields field in all nodes.

For example, the following code fragment is legal in an Inventor 2.1 file:

Cube {
    fields [SFFloat width,
            SFFloat height,
            SFFloat depth,]
    width 10
    height 4
    depth 3

The “isA” Field

When a new node type is a superset of an existing node, and an implementation for the new node type cannot be found, the new node type can be treated as the existing node it is based on (with some loss of functionality).

To support this, new node types can define an MFString field called isA containing the names of the types of which it is a superset.

For example, assume a new subset of Material called ExtendedMaterial adds the index of refraction as a material property. This type can be defined as follows:

ExtendedMaterial {
  fields [ MFString isA, MFFloat indexOfRefraction,
           MFColor ambientColor, MFColor diffuseColor,
           MFColor specularColor, MFColor emissiveColor,
           MFFloat shininess, MFFloat transparency ]
  isA [ "Material" ]
  indexOfRefraction .34
  diffuseColor .8 .54 1

If the ExtendedMaterial node is not known, an alternateRep field containing an SoMaterial node is automatically created.

Miscellaneous Additions

This section briefly discusses:

SoGLRenderAction Render Abort Callback Changes

The render abort callback in Open Inventor 2.1 no longer returns a simple Boolean value. Instead, it returns an abort code (similar to the SoCallbackAction::Response code) that is one of CONTINUE, ABORT, PRUNE, or DELAY.

  • CONTINUE is the same as returning FALSE in previous versions of Inventor; it means that rendering should continue as usual.

  • ABORT is the same as returning TRUE in previous versions; it terminates the current render traversal.

  • PRUNE indicates that traversal should skip the current node and all nodes under it.

  • DELAY postpones traversal of the current node until after all other nodes have been traversed, just like the SoAnnotation node.

PRUNE and DELAY are new features that allow applications to modify Inventor's standard rendering order.

New Manipulator for Transformations

A new manipulator, SoTransformerManip, has been added to the set of Inventor manipulators. It provides a full interface for rotation, translation, and scale in three dimensions. This new manipulator provides better feedback than the older manipulators, and uses the new locate highlighting feature to indicate which of its parts to pick. See the reference page for more details.

SoTransformerManip is used in IRIS Annotatorand WebSpace Author.™.

OpenGL Texture Object Extension

Open Inventor 2.1 makes use of the OpenGL extension for texture objects. Consequently, you see improved texture mapping performance on systems where this OpenGL extension is available.

SoXtViewer Changes

There are two changes to SoXtViewer:

  • When a viewer is in pick mode, you can temporarily switch to view mode by holding down the <ALT> key.

  • The method SoXtViewer::setCursorEnabled() allows you to specify whether the viewer is allowed to change the cursor over the render area window. Disabling the cursor enables the application to set the cursor directly. This is useful, for example, if you want to set a busy cursor in the window.

New and Updated Utilities

The following new and updated utilities are available in Inventor 2.1 and are discussed in this section:

Note: The utility program ivquicken is no longer supported.

File Downgrade Utility

A new utility program, /usr/sbin/ivdowngrade, takes an Inventor file and converts it to Inventor version 2.0 or 1.0. See the reference page for more details.

Program for Converting Files to Use Vertex Properties

The ivAddVP utility program helps convert Inventor files into 2.1 files that use the vertexProperty field for the vertex-based shapes. The source code, including a Makefile, is distributed in the inventor_dev.src.sample subsystem. It is installed in the directory /usr/share/src/Inventor/tools/ivAddVP.

Program for Optimizing Scene Graphics

A new utility program, /usr/sbin/ivfix, restructures Inventor scene graphs for improved rendering performance. ivfix first analyzes the organization of the input scene graph and tries to sort it to take advantage of coherence. For example, it tries to organize subgraphs by common textures, since switching textures is expensive. Once sorting is complete, ivfix also tries to combine subgraphs so that the final result has fewer nodes. Finally, ivfix “flattens” the subgraphs, tessellating all shapes into triangles that are then organized into triangle strips. For example, two spheres may be combined into one triangle strip.

The source code to ivfix, including a Makefile, is distributed in the inventor_dev.src.sample subsystem. It is installed in the directory /usr/share/src/Inventor/tools/ivfix.

Program for Analyzing Rendering Performance

The utility program ivperf, for analyzing rendering performance, is provided in source code format in the inventor_dev.src.sample subsystem. It is installed in the directory /usr/share/src/Inventor/tools/ivperf. For information on ivperf, see Chapter 6, “Optimizing Open Inventor Applications.”