Compatibility Notes

Open Inventor 9.4 (May 2014)

Older compatibility notes

Please at least glance through these compatibility notes so that you are not surprised by any differences in behavior between this release and the previous release.



Technical overview

You should completely recompile existing applications after installing a new version of Open Inventor.
New versions of Open Inventor are source code compatible (unless noted in this document), but not binary compatible.

New Classes

  • SoCameraInteractor
  • SoDeviceSettings
  • SoHeightFieldPropertyMask

New Fields/Enums in Existing Nodes

  • SoTextProperty::styleColorUseCurrentMaterial
  • MoDrawStyle::fadingThreshold

Open Inventor

SoExtSelection takes in account SoClipPlane during selection

We have improved the selection and now we take in account SoClipPlane during selection (clipped shape will be no longer selectionable). To retreive the previous behaviour you can used the environment variable OIV_SELECTION_USE_CLIPPLANES set to zero. 

VolumeViz

Enhanced performance for texture generation (non-LDM and compressed volumes)

  • The new mechanism can be deactivated by setting the environnement variable LDM_USE_PREFETCH_OPTIM to false.
  • In most case, the variable LDM_USE_IN_MEM_COMPRESSION is no longer required

MeshViz XLM (C++ API only)

Optimization of mesh skin extraction 

  • The new cache generates a small overhead as it just needs 1 or 2 byte per mesh cell, (2 bytes if a cell filter is used)

RemoteViz

API evolution since the first beta version

To take in account all feedbacks received since the beginning of the beta program of RemoteViz, we have introduced some small evolutions in the API: 

  • We introduce two run mode in order to change the behavior of the RemoteViz events loop :

    • Standalone mode: requires a loop to run the RemoteViz application (see HelloCone example).

    •  InventorApplication mode: uses the main loop of an existing Open Inventor application (see InventorApplication example). 

The used mode can be set in the open method of the RemoteViz service. The default behavior is Standalone.

  • In order to ease the use of RemoteViz listeners and the memory management in the applications, RemoteViz now requires shared pointers for listeners. std::shared_ptr (C++11) is a smart pointer that retains shared ownership of an object through a pointer.
std::shared_ptr<MyServiceListener> serviceListener;
serviceListener = std::shared_ptr<MyServiceListener>(new MyServiceListener());
Service::instance()->addListener(serviceListener); 
  • After setting up the Open Inventor extensions used by your application with a call to "setUsedExtension", RemoteViz now loads and initializes the modules. The call to method “TheExtension::init()” is now useless.
  • The “onRender” callback has been renamed “onPostRender”. It is triggered when a rendering is done.

  • The new “onPreRender” callback has been added. It is triggered before a rendering is done. This callback enable you to prevent rendering or control the clear policy for color and depth buffer.

Examples

  • The InventorApplication example has been added in the package to show how to add  RemoteViz in an existing Open Inventor application.

  • The ConnectionManagement example has been added to demonstrate how to accept or refuse a new connection depending credential provided as parameters on the service URL.

  • The SceneExaminer library has been removed from the RemoteViz package. This library has now been included as a demonstration in the Open Inventor package.

Java API Specific

SbMatrix: getRow() behavior changed, new method getColumn()

Previously the SbMatrix method getRow(int) actually returned a column of the matrix (bug #17530).  This incorrect behavior was changed and a new method, getColumn(int) was added. If you have code like this to get a column of the matrix:

SbMatrix matrix . . .
float[] col = matrix.getRow( 0 );  // Actually returned column 0 before OIV 9.4

You must change it to:

 float[] col = matrix.getColumn( 0 ); 

Fixed bugs

Since 9.3.1, in the page " Fixed bugs" the bug tracking numbering has evolved to reflect internal improvement on issues management. New bug numbers have now five digits (old have only four digits).  For some bugs present in both system you can lookup the corresponding old number format in the comment, for example in the case #17604 you will find the comment [eBUG#5414] ...