Before starting

Open Inventor 10.0 is the latest major version. Compared to Open Inventor 9, many new features and improvements have been provided in version 10.0 as well as in the subsequent minor versions.

As a major release it also means some behavior change or some old deprecated features and APIs have been removed. That may lead your applications built with Open Inventor 9 to not build anymore with the latest version. In order to help you to upgrade easily to the latest version of Open Inventor, we gathered a list of actions which may help you through the upgrade process.

General information

Life Cycle

As for each major version, Open Inventor 10 introduces some deprecation management and because this is a major release it's important to remember what is done exactly

  • All methods, nodes, classes and fields set as deprecated before Open Inventor version 8 have been removed from the public API and are no longer available.
  • All methods, nodes, classes and fields set as deprecated between Open Inventor version 8 and version 10 that have currently no effect on the application have been removed from the public API and are no longer available.

Open Inventor provides a convenient tool to detect what part of your application will need some attention by detecting usage of deprecated classes/API/fields/Nodes. Before using this tool it's greatly recommended to switch to the 9.6.2 or higher version of Open Inventor. Then simply add the pre processor definition #define SO_VERSION_DEPRECATED_ERROR 10000 at the top of your code and compile it.

In a such configuration, each time a deprecation feature is used an error is generated. This will point out the code that needs to be changed to be compliant with Open Inventor 10. In most of cases if, in this configuration, your application is successfully built upon Open Inventor 9.6.1 or higher then the move to Open Inventor 10 should be straight forward.

Please be aware that the build done while using SO_VERSION_DEPRECATED_ERROR must not be used for run as the mechanism misaligns headers used by Application and headers really used by Open Inventor libraries.

Unfortunately some code may not have been detected by this tools and will need your attention once, and only once, you'll try to build your application upon Open Inventor 10. Following chapters will enumerate them for each modules.

Removed modules, classes and old code

Following modules have been removed and won't be replaced, so there is currently no way your application may build if you use one of the following:

  • MeshViz XLM.NET
  • FXViz
  • DirectViz
  • SolidViz
  • TerrainViz
  • PoXT API
  • ScaleViz
  • HardCopy editor classes: by then PoPrintCGMMonitor, PoPrintHPGLMonitor, PoPrintMonitor, PoPrintPSMonitor are not available anymore
  • MeshViz editor: they used to provide GUI editors for some MeshViz classes that used PoXt. As long as PoXt has been removed, MeshViz editors have also been removed from the public API. These editors and all the demos using them have been ported to DialogViz and can be found in the demo directory.
  • SoToZ3dAction : has been removed from the public API as it was obsolete.
  • SoGLRenderCache / SoGLCacheList / SoGLDisplayList are not public anymore. You can still use associated Open Inventor class but you will not get the same low level access than before.
  • Because of the very few number of GPU supporting these features, all functions and classes related to IndexedColor and Overlay have been remove from the public API.
  • The (very old) macro IV_STRICT is no longer used and we recommend to remove IV_STRICT from all projects and source code.
  • The CUDA and OpenCL classes have been removed from the API
  • Here is a exhaustive list of non supported fields in Open Inventor 10

NOTE: Please see also the specific sections below (Open Inventor, VolumeViz, etc) for more details. Do not hesitate to contact-us to request help if any of these module was useful for the development of your application.

Custom nodes management

The option for applications to create custom nodes is still a key part of the Open Inventor architecture. Custom nodes allow applications to extend the capabilities of the scene graph.  Custom nodes can combine the features of existing nodes (composite pattern) or add completely new features. All custom nodes will require at least some small changes to be used in Open Inventor 10.  Here is short

Starting with Open Inventor 10, all graphics API calls are executed by a render engine, a software layer between hardware and Open Inventor public API. This render engine layer makes the Open Inventor public API independent of the low-level graphics API. This design has many advantages, including, maintenance, optimizations and future graphics API support. On the other hand, the new design requires some changes in application code, especially for custom nodes which require strict guidelines compared to previous versions.

You will find all the necessary information in the complete guide on this page.

Render Caching

Open Inventor automatically uses “render caching” to optimize rendering performance. For example, the rendering commands in the cache can be optimized independent of the application’s scene graph structure. Also, render caching makes it unnecessary to traverse parts of the scene graph that have not changed since the previous render traversal.

In older versions of Open Inventor this feature was based on OpenGL "display lists". Display lists depended on undocumented behaviors of each vendor’s graphics driver and, in some cases, required “hints” from the application. In Open Inventor 10, render caching is now completely automatic and completely managed by Open Inventor. Here we highlight some specific changes.

  • SoTransformation
    In previous versions of Open Inventor, modifying a transform node (SoTransform, SoTranslation, etc) would invalidate the render cache for its parent SoSeparator (and its parent and so on). Applications would normally add additional SoSeparator nodes to preserve render caches for geometry below the transform node. This additional scene graph structure is not necessary in Open Inventor 10. Modifying a transform node does not affect render caches.

  • SoSeparator
    Applications should no longer modify the value of the renderCaching field. In Open Inventor 10, modifying this field can actually reduce performance. The renderCaching field is deprecated and will eventually be removed from the API.

  • SoDB
    The setNumRenderCaches() and setRenderCacheMode() methods have no effect in Open Inventor 10. Scene graph patterns that previously required multiple render caches are handled with a single render cache in Open Inventor 10. Likewise, the SoPreferences variable OIV_MAX_CACHES has been removed in Open Inventor 10.

  • So(XXX)RenderArea
    There is a compatibility issue for applications that create multiple render areas (SoXtRenderArea, SoWinRenderArea, etc). Each SoXXXRenderArea creates an OpenGL render context and, by default, requests that the context be “shared” with the current context. As a result, all the render area contexts will be part of the same OpenGL “share group”. Open Inventor 10 will attempt to use a single render cache for all contexts in a share group. However this is not possible for multiple render areas and will result in poor performance. The problem is avoided if the render area contexts are not shared. Applications should call renderArea->getNormalSoContext()->setSharable(false) immediately after creating the render area.

From SoOffscreenRenderer to SoOffscreenRenderArea

Most of features of SoOffscreenRenderer are available in OpenInventor 10. Many features have been moved to the new class SoOffscreenRenderArea. However, some methods have been renamed or moved to other public classes. See this page for some hints and below for more details.

  • Large area is still possible with SoOffscreenRenderArea. One can see in the reference manual of SoOffscreenRenderArea: The renderer can render very large images because it is able to render the scene as multiple "tiles" and assemble the tiles into a complete image. Of course this requires multiple render traversals of the specified scene graph (one for each tile). Moreover because SoOffscreenRenderArea  now allows image of infinite size old SoOffscreenRenderer::getMaximumResolution has become useless
  • If you need to use a specific image writer to save the generated render (meaning you don't want to use the new renderToFile method) you will have to
  • The result equivalent to the old call to SoOffscreenRenderer::getScreenPixelsPerInch is available by calling SoGLScreenDevice::getPhysicalSize() / SoGLScreenDevice::getResolution()
  • SoOffscreenRenderer::setRegion_i32 is not available directly but using this type of C++ code

const SbVec2i32 windowSize( 512, 512 );
const SbVec2i32 subRegionOrigin( 0, 0 );
const SbVec2i32 subRegionSize( 256, 256 );
SbViewportRegion vvp( windowSize );
vvp.setViewportPixels( subRegionOrigin, subRegionSize );
SoOffscreenRenderArea* ora = new SoOffscreenRenderArea;
ora->setViewportRegion( vvp );


Starting with its version 10, Open Inventor provides a complete GLSL shader API to access various state values from shaders. It which brings some useful functions separated into two different headers files.

  • State accessors: are functions defined to get information from the state. It covers transformation, lighting, material and clip plane properties. These properties are accessible whatever the shader pipeline stage is. The include gathering these functions can be found in the file $OIVHOME/shaders/include/Inventor/oivShaderState.h
  • Shape Attribute accessors: The functions define a generic way to access implementation dependant values. It covers vertex attributes as well as shape instance attributes. These functions are available only from the vertex shader. All these methods are gathered in the include file $OIVHOME/shaders/include/Inventor/oivShapeAttribute.h

In order to simplify the use of this shader API, Open Inventor 10 also provides a simple tools to replace GLSL built-in uniforms into OIV shader API calls, providing therefore a way to port shaders that work in Open Inventor 9.x to shaders working in Open Inventor 10 as well. The tool is a python script named (compatible with python 2.x) that can be found in the directory $OIVHOME/src/Inventor/tools/GLSLConverter

Finally, you'll find all the needed information for writing shaders wih OIV 10 on this dedicated page

NOTE: In most cases this discussion does NOT apply to simple VolumeViz shader functions.  Most simple VolumeViz shader functions, for example a replacement VVizComputeFragmentColor() function, will work with Open Inventor 9.x and 10.x.

VRML Migration

Regarding VRML, Open Inventor brings some huge changes

  • All the SoVRML classes (nodes and actions) have been removed from the API.
    These classes were rarely used in Open Inventor applications and are not required to import and use geometry from a VRML format file.  Also most of these classes duplicated features in standard Open Inventor nodes that are better implemented and much more optimized.
  • Import: Importing geometry from a VRML (.wrl) file is still supported.
    Just use SoInput and SoDB::readAll() as usual.  There are two important changes:

    • The resulting scene graph will now contain only standard Open Inventor nodes.
      For example, VRML IndexedFaceSet nodes are converted to SoIndexedFaceSet nodes.
    • Only geometry related nodes (shapes and attributes) are imported.
      Some nodes, for example Viewpoint, are not currently converted.  Please let us know if you have additional requirements.
  • Export: It is not currently possible to export a scene graph to VRML format.
    Please let us know if this is a requirement.

Please see below how some nodes can be replaced by some standard Open Inventor nodes. If your application is using nodes not documented, please contact-us for support.

VRML Node used Can be replaced by  / Simulated with
SoVRMLBackground SoGradientBackground / SoImageBackground
SoVRMLBillboard SoBillboard
SoVRMLBox SoCube
SoVRMLCollision No strict equivalent. See SoCollisionManager
SoVRMLColor SoMaterial + SoLightModel
SoVRMLColorRGBA SoMaterial + SoLightModel
SoVRMLCone SoCone
SoVRMLCoordinate SoCoordinate3
SoVRMLCylinder SoCylinder
SoVRMLDirectionalLight SoDirectionalLight
SoVRMLExtrusion SoExtrusion
SoVRMLFog SoEnvironment
SoVRMLFontstyle SoFontstyle
SoVRMLGroup SoSeparator
SoVRMLImageTexture SoTexture2
SoVRMLIndexedFaceSet SoIndexedFaceSet
SoVRMLIndexedLine SoIndexedShape
SoVRMLIndexedLineSet SoIndexedLineSet
SoVRMLIndexedShape SoIndexedShape
SoVRMLIndexedTriangleFanSet SoIndexedTriangleFanSet
SoVRMLIndexedTriangleSet SoIndexedTriangleSet
SoVRMLIndexedTriangleStripSet SoIndexedTriangleStripSet
SoVRMLLineSet SoLineSet
SoVRMLLOD SoLevelOfDetail 
SoVRMLMaterial SoMaterial
SoVRMLMultiTexture SoTextureUnit + SoTexture2 + SoShaderProgram
SoVRMLMultiTextureCoordinate SoTextureUnit + SoTextureCoordinate2
SoVRMLMultiTextureTransform SoTextureUnit + SoTextureTransform
SoVRMLNode SoNode
SoVRMLNormal SoNormal
SoVRMLParent SoGroup
SoVRMLPixelTexture SoTexture2
SoVRMLPointLight SoPointLight
SoVRMLPointSet SoPointSet
SoVRMLPolyline2D SoLineSet
SoVRMLPolypoint2D SoPointSet
SoVRMLShape SoSeparator + SoMaterial + SoShape
SoVRMLSphere SoSphere
SoVRMLSpotLight SoSpotLight
SoVRMLStaticGroup SoSeparator
SoVRMLSwitch SoSwitch
SoVRMLText SoText3
SoVRMLTexture SoTexture2
SoVRMLTextureCoordinate SoTextureCoordinate2
SoVRMLTextureCoordinateGenerator SoTextureCoordinateFunction
SoVRMLTextureTransform SoTexture2Transform
SoVRMLTransform SoSeparator + SoTransform
SoVRMLTriangleFanSet SoTriangleSet or SoTriangleStripSet
SoVRMLTriangleSet SoTriangleSet
SoVRMLTriangleSet2D SoTriangleSet
SoVRMLTriangleStripSet SoTriangleStripSet
SoVRMLVertexShape SoVertexShape
SoVRMLWorldInfo SoInfo

Unsupported fields

With Open Inventor 10 a lot of fields are now not supported anymore. It means they won't have any effect on the scene graph, even if they are present and have a particular value. When loading a scene graph including unsupported fields, a warning message should appear in the console

Inventor warning in SoField::read(): Field <ClassName::FieldName> is no more supported.

This does not mean any error happened but simply that the field is not taken in account in this scene graph. To remove warning messages simply delete all references to the given field in the scene graph.


In Open Inventor 10 a huge rework of the transparency has been done. SoTransparencyType and SoTransparencyTypeElement classes are no more available. To retrieve or set the Transparency type you must now use the SoGLRenderAction class and the following methods:

  • SoGLRenderAction::getTransparencyType() instead of TransparencyTypeElement::get
  • SoGLRenderAction::setTransparencyType() instead of TransparencyTypeElement::set

Transparency types available in SoGLRenderAction::TransparencyType translates how objects are sorted. Available values are:

  • NO_SORT (The default) is the equivalent to the former BLEND mode
  • OPAQUE_FIRST is the equivalent to the former DELAYED_BLEND mode
  • SORTED_OBJECT is the equivalent to the former DELAYED_SORTED_OBJECT_BLEND mode
  • SORTED_PIXEL is the equivalent to the former DELAYED_SORTED_PIXELS_BLEND more

To match Open Inventor 9's transparency mode please use the following table of correspondences

Open Inventor 10 Open Inventor 9

Open Inventor 10 limitation: SoBlendElement is not supported when using transparency type SORTED_PIXEL.

On another hand, to manage the way Alpha is interpreted, Open Inventor 10 introduces the new node SoAlphaPolicy, providing, through the POLICY enum, three different policies:

  • POLICY_AS_IS : fragment's alpha value is used as is
  • POLICY_OPAQUE : all semi-transparent fragments are considered as opaque
  • POLICY_DISCARD : all semi-transparent fragments are considered as fully transparent

Notification mechanism

Notification mechanism has been changed in Open Inventor 10. Until now, each time a value was assigned to a field, a notification was generated and processed by Open Inventor. Now, if a field is given a value equal to its current value no notification will be generated.

This new behavior may not change the way your application currently works, as it is mainly internal. By the way it could help you to clean your code by removing (if present) some test where you had to check that new field's value was different from previous one.

Please note that there's still two little side effect to this new behavior.

  1. When recording your scenegraph in an iv file, fields with default value are not serialized. Mainly if you set a field to its default value when it is already equal to its default value then save your scenegraph the field won't appear in the generated file as it used to in previous version. The same behavior has been applied on Multiple fields but only when using the method set1value.
  2. The second effect of this new behavior is that if you defined a custom field container you will notice, when calling the SO_SFIELD_SOURCE macro, that its equality operator is called before its assignment operator. To implement the new behavior on notification we have added some test on the field container before assigning any value. For this reason, with custom field container, by virtuality, the equality operator is now called first.

Import / Export

Support for the following file formats has changed in Open Inventor 10:

  • VRML: Import of VRML (.wrl) files is still supported but native Open Inventor nodes are created.
    The VRML API, e.g. SoVRML nodes, has been removed.
    Export to VRML is not supported in Open Inventor 10.
    If VRML is something really needed to develop your application contact-us to express your requirements.
  • OpenFlight: Import of OpenFlight files is not supported in Open Inventor 10Contact-us if you need some help to remove the use of the reader from your application.


  • In Open Inventor 10, VolumeViz LDM does not manage memory as it used to. Now each SoVolumeData can manage the way tiles are loaded in the LDM cache. The meaning of loaded in LDM cache is
    • For in memory volume: tiles are built by the reader and stored in the LDM cache. In this case, data are duplicated.
    • For a compressed LDM file: tiles are uncompressed by the reader and the uncompressed buffer is stored in the LDM cache.

    Since Open Inventor 9, LDM is able to manage compressed tile in memory. The feature used to be global and was managed through the SoLDMGlobalResourceParameters class. Starting from Open Inventor 10, the feature will be more flexible and control will be per SoVolumeData.
    For this purpose a new field, named tileCachePolicy has been added to node SoLDMResourceParameters. It specifies which tiles should be loaded in LDM memory or which can be generated on the fly. Please refer to the relative documentation to get more information.
    Because this feature greatly impact on the interactivity, tileCachePolicy is set by default to ALL, so all tiles requested by LDM will be generated by the readers and loaded in the LDM cache. When LDM needs the tile, it's already available for direct access.

  • To improve default volume rendering quality (ie: with no particular tuning) some parameters have been slightly changed.  Because of this it's possible that you notice some minor differences with previous Open Inventor version when launching your application. Here is the list of default parameter that have been updated. If you want to restore the previous behavior simply set the associated property to the old value
    • Fields from SoVolumeRender
      • numSlicesControl: has been switch from ALL to AUTOMATIC. This value let you adjust the sliceNumer with SoComplexity = 0.5 (default value)
      • samplingAlignment: has been switch from VIEW_ALIGNED to BOUNDARY_ALIGNED. Note that this value gives less slicing artefacts but is only available in raycast mode. If raycast is not supported Open Inventor switches automatically to VIEW_ALIGNED.
      • opacityThreshold: has been defined to 0.1 by default instead of 0. Will give better results when using semi-transparent color map.
    • Fields from SoVolumeShader
      • interpolateOnMove: is now activated by default (TRUE instead of FALSE). May have a little impact on framerate if you're using a low-end GPU.
    • Fields from SoVolumeRenderingQuality
      • preIntegrated: is now activated by default (TRUE instread of FALSE). It will give smoother results and limits slicing artefacts.
      • lightingModel: field is now deprecated and the OpenGL lighting model is always used. If, for any reason, you need to retrieve the behavior you had with the OIV6 value you'll have to tune the SoMaterial properties. Contact-us if you need some help to switch to OpenGL lighting model or if you have some troubles to get the OIV6 lighting model result.
      • deferredLighting: is now activated by default (TRUE instead of FALSE).
    • Field from SoSlice
      • alphaUse: is now set on ALPHA_OPAQUE instead of ALPHA_BINARY previously.
    • LDM Parameters
      • Default tile size: the default tiles size for volume data is now (128,128,128) instead of (64,64,64). If you want to get back to the old value, just use the tileDimension field of the SoLdmResourceParameters associted to your SoVolumeData.
    • Default value of the field refinementDelay of node SoInteractiveComplexity is now 0.0 by default. You can recover previous behavior by setting the value to 0.5
    • Several classes have been removed so they are not available anymore.
      • SoLDMTileManager
      • SoLDMTileManager::LDMSliceAccessor
      • SoLDMTileVisitor
      • SoLDMProximityVisitor
      • SoLDMNodeFrontManager
      • SoLDMMediator::LDMManagerAccess
      • LDMDefaultSliceAccessor
      • SoLDMGeometry
      • SoLDMGeomElement

      As a direct consequence this is not possible anymore to define your own Tile Manager. If your application implemented a custom tile manager you will need to remove it and let LDM manages itself the loading of tiles. If you were using this feature for a particular reason, please do not hesitate to contact-us to request help about how not using a custom tile manager. Another consequence of this move to private directory is that all setters and getters for these class have been set private too in all classes defining such methods. Nevertheless some methods have been moved to SoDataSet because of their utility from an application point of view.

      • isInMemory(SoLDMTileID tileID)
      • isDataInMemory(SoLDMTileID tileID)
      • getTileIDInMemory(std::vector& tilesInMemory)
      • setMonitoringCB() (because SoLDMMonitoringCB use an SoLDMTileManager)

      Also, a method called getLDMTopoOctree() has been added to SoDataSet because it can be useful to access functions like

      • getTilePos( tileId )
      • getTileID( cellPos, resolution )
      • int getLevelMax()
      • int level( tileId )

      These functions from SoLDMLargeDataManagement have been also removed and won't be available anymore. As long as there is no replacement solution, please contact-us to request some support in case your application was using one of them.

      • SoLDMTileManager* getTileManager() const
      • SoLDMTileVisitor* getTileVisitor() const
      • SoLDMTextureManager* getTextureManager() const
      • SoLDMGeometry* getVVizGeometry() const
      • SoLDMNodeFrontManager* getNodeFrontManager() const
      • SoLDMResourceManager* getResourceManager() const
    • SoSearchDepthOffsetAction and SoLdmValuationAction are not public anymore. They were no particular reason for these actions to be public and there is no real reason for any application to use them. If, by any mean, your application used them please contact-us to request some support in case you facing troubles.
    • The Slabbing, previously available in VolumeViz rendering, has been removed from the public API. Shaders have been greatly optimized and algorithms such tiling also prevent from any Timeout Detection & Recovery issue. So as a consequence, in class SoVolumeRender following members are not available anymore:
      • bool isSlabbingEnabled(SoState* state) const
      • static int s_volumeRaycastSlabbingMode;

      and following shaders, in $OIVHOME/shaders/VVizPipeline, have been updated

      • FRAGMENT_COMPOSITION: vvizAlphaBlending_frag.glsl
      • FRAGMENT_MAIN: vvizVolumeRaycast_frag.glsl
      • FRAGMENT_OUTPUT_COLOR: vvizDefaultOutputColor_frag.glsl
      • FRAGMENT_RAYCASTING_FUNCTION: vvizRaycastCommon_frag.glsl
      • FRAGMENT_RAYCASTING_FUNCTION: vvizRaycastCommon_frag.h
      • VIRTUAL_TEXTURE_FUNCTIONvvizVirtualTexture_frag.glsl
    • Remove field maxNumTriangles of SoLDMResourceParameters. Replaced by the current value of the SoComplexity.



Open Inventor now fully supports QT 5 and uses the version 5.9 of the well known GUI library. This new feature introduces two major changes from an application point of view

  • It's now mandatory to install Qt 5.9 on your machine if you wish to rebuild any demo contained in the Open Inventor package. If you just want to run these demos, the installation is not mandatory, but to rebuild them, Qt 5.9 must be installed on the developper computer.
  • On OS X the introduction of Qt 5.9 leads us to provide a fully compatible installer allowing a fast and reliable distribution. To support such feature, Open Inventor 10 binaries (libraries and executable) or now built upon the RPATH mechanism. In extension, any QT application based on Open Inventor will need to use the same mechanism in its deployment process.
  • Open Inventor 10 uses the QOpenGLWidget as main class for QtViewerComponent. Please refer to the official documentation of QOpenGLWidget to get more information about methods that may not be available anymore compared to the old QGLWidget used previously.

Open Inventor

Default Behavior

  • Multithread: Starting with version 10, Open Inventor is now multithreaded by default and there is no way to turn the feature off. From a performance point of view, if your application was previously not using this mode, there should have no impact. If you think your application is penalized by this change, please contact-us to ask for support.
    If your application was using the multithread mode, you may have to make some changes in the code:

    • SbThreadRWMutex/SbThreadMutex constructors that take a bool are now deprecated. There is simply no more reason to pass a boolean to their constructor as the multithread support is the only one available. To prevent future compilation error you can remove every call to the constructor of these classes done with a parameter.
    • threadInit() methods of all submodules are now deprecated as the corresponding init() method behaves like threadInit. Following methods can be replaced in your application
      • SoInventorBase::threadInit() must be replaced by SoInventorBase::init()
      • SoDB::threadInit() must be replaced by SoDB::init()
      • SoInteraction::threadInit() must be replaced by SoInteraction::init()
      • SoNodekit::threadInit() must be replaced by SoNodekit::init()
      • SoGui::threadInit() must be replaced by SoGui::init()
      • SoWin/Xt/Wx/Qt::threadInit() must be replaced by SoWin/Xt/Wx/Qt::init()
    • Environnement variable OIV_MULTITHREAD has no more effect.
    • SoDB::isMultiThread() is now deprecated and will always return TRUE
    • As a direct simplification of the deletion of non multi-thread support, you don't need anymore to call ThreadInit() on each thread using Open Inventor. Now A simple call to Init() in the main thread is needed for each module you may want to initialize.
  • All SbVec and all SbMatrix classes are now initialized with zeros instead of not being initialized at all. This has been done to provide a a safer API as well as some consistency with JAVA and .NET API.


  • Open Inventor 10 will no longer supports CG and ARB shaders. This means all shaders written in these languages have to be rewritten using GLSL.

Nodes and classes

  • SoRef has been modified so the implicit cast operator of SoRef<> has been removed. If you followed previous step describing how to detect Deprecated API removal you should not have any issue with this. In any case, to cast into C pointer a SoRef it's now mandatory to use explicit ptr() call.
  • A bug has been fixed in any classes inheriting SoDeviceContext. In previous version they used to have a default refcount set to 1 in their constructor. This was obviously a bug. As long as the bug is now fixed, application should ensure that it keep a reference of the object on its own side (when it make sense) to avoid Open Inventor deleting the object on last used. Here's a typical previous usage:
    SoGLContext *m_oglContext = new SoGLContex(...);
    ...some action that may ref/unref the context

    In this code the first line (the one creating the object) should be replaced by this one

    SoRef <SoGLContext> m_oglContext = new SoGLContex(...);

    A similar change must also be done for the class SoCpuContext

    To help you detect potential issues, you can set the environnement variable OIV_GLCONTEXT_REF_WARNING to TRUE. This will generate a warning each time a context with a refcount equal to 0 is used. To disable the warning just set the variable to FALSE.

  • All SoGLXXXElement classes have been removed and are not available anymore. As a replacement each SoGLXXXElement object should be replaced by the equivalent SoXXXElement (no GL prefixe. For example, SoGLPolygonOffsetElement must be replaced by SoPolygonOffsetElement).
  • SoGLCacheContextElement is one of the elements removed from the public API that has not been replaced by any SoCacheContextElement as explained above. For now only the shouldAutoCache method has been kept and is now available the SoGLRenderAction class
  • SoBillboard: because of the removal of the VRML API, Open Inventor introduces this new node with the exact same properties than the removed SoVRMLBillboard. In your application, simply parse the code and replace any occurrence of SoVRMLBillboard with SoBillboard.
  • SoExtSelection: all methods have been replaced by fields so the node provides a consistent API with other Open Inventor node. If your application uses this node, please replace deprecated methods with the appropriate field as described below:
    • void setOverlayLassoColorIndex(int index) -> not supported anymore. Calling the function does nothing
    • int getOverlayLassoColorIndex() -> not supported anymore. Function will always return 0
    • void setLassoColor(SbColor c) -> set color using field lassoColor
    • SbColor getLassoColor() -> get lasso color using field lassoColor
    • void setLassoWidth(float width) -> set lasso width using field lassoWidth
    • float getLassoWidth () -> get lasso width using field lassoWidth
    • void setOverlayLassoPattern (unsigned short pattern) -> set lasso pattern using field lassoPattern
    • unsigned short getOverlayLassoPattern () -> get lasso pattern using field lassoPattern
    • void animateOverlayLasso (SbBool flg=TRUE) -> define the animated property using field animateLasso
    • SbBool isOverlayLassoAnimated () -> get animated property using field animateLasso
    • Field lassoPatternScaleFactor has also been added to stretch the lasso pattern by multiplying each sub series of consecutive 1s and 0s. Scale factors are clamped to lie between 1 and 255. Default is 1
  • SoCameraManager: has been removed from the public API. There were no real reason for this class to be available from the public API and there is also no reason any application may use it. If, for any reason, your application was using it, please contact-us to request support on this issue.
  • SoFrontBufferGroup: has been removed from the public API. The features provided by this class can be re implemented with SoAnnotation node
  • SoTextureCubeMap: it's not possible anymore to fill a SoTextureCubeMap with 6 textures in different format. Moreover, textures used to define the SoTextureCubeMap must have the same square size. If conditions are not respected an error message is displayed (in debug) and nothing is changed on the state
  • SoTexture API has been greatly simplified. Our API covers all types of hardware texture. So, if you need to implement a new texture for a particular purpose, you must use a derivation of one of the existing types (e.g. SoTexture2, SoTexture3, ...). Remember that GLRender of your texture must call GLRender from its super class (e.g. SoTexture2::GLRender if texture inherits from SoTexture2 for example)
  • SoTexture::ALPHA4, SoTexture::LUMINANCE4 and SoTexture::INTENSITY4 were set deprecated in Open inventor 9.6.2 and are not available anymore. As a remplacement please use the 8 bits version of the type with the same name (ie: SoTexture::ALPHA8, SoTexture::LUMINANCE8 and SoTexture::INTENSITY8)
  • The API provided by SoLicensedProduct has been drastically rewritten as the previous one was not very convenient. If you have any issue to use this brand new API do not hesitate to request needed support.
  • All legacy MP viewers have been removed and are now not available anymore (Classes you were able to find in $OIVHOME/include/Inventor/MP).
  • SbVec constructors from C arrays are now explicit. Starting with Open Inventor 10 direct affectation of a C array to the appropriate SbVec will generate a compilation error if the C array is not casted to the right type before. For example this code float vertice[3] = { 0.724f, 0.526f, -0.447f };
    SbVec3f mySbVec = vertice;
    will not compile anymore and generate the following compilation error

    error C2440: 'initializing' : cannot convert from 'float [3]' to 'SbVec3f'

    To be sure your code is compliant with this new standard you have to cast the C array before the affectation

    float vertice[3] = { 0.724f, 0.526f, -0.447f };
    SbVec3f mySbVec = SbVec3f(vertice);

  • SoFrameBufferObject/SoGLRenderToBuffer/SoPBuffer have all been removed from the public API. As a replacement solution your application can use the node SoRenderToTarget. Be sure to check documentation as this node is a group node that renders its children to one or more render targets.
  • Methods relative to license have been moved from SoDB to SoLicenseInfo class:
    • SoDB::LicenseCheck() must be replaced by SoLicensesInfo::check()
    • SoDB::getVersion() must be replaced by SoLicensesInfo::getVersion()
    • SoDB::getLicensingVersionNumber() must be replaced by SoLicensesInfo::getLicensingVersionNumber()

    Please note that this modification has been done in C++, Java and .NET Apis.

  • SoLazyElement: the node is deprecated in Open Inventor 10. As a replacement you should use the new SoMaterialElement allowing you to manage several properties needing to be lazily tracked for OpenGL.
  • SoTexture::useAutoMipmap : the field has been removed because of its uselessness. Meanwhile, mipmaps are always generated when needed (automatic detection).
  • SoShadowGroup::SHADOW_MAP enum value has been removed. Please use VARIANCE_SHADOW_MAP instead as it provides better results with similar performances.
  • SoRenderToTextureProperty has been changed to be consistent with Open GL and DirectX. So to be used with a SoTextureCube map, the six scene graphs must be specified in the following order:
    • left : imagePosX (formerly imagePosX)
    • right : imageNegX (formerly imagePosY)
    • bottom : imagePosY (formerly imageNegX)
    • top : imageNegY (formerly imagePosZ)
    • back : imagePosZ (formerly imageNegY)
    • front : imageNegZ (formerly imageNegZ)

    Please also note that the PBuffer implementation is no more supported. SoRenderToTextureProperty is now based on FBO.

  • SoRenderList and children nodes SoOcclusionCulling, SoOctreeOrdering and SoValueOrdering have been removed from the public API. Features are no more supported by these nodes, so simply replace any of these nodes by a SoSeparator


  • The method getColorMapper() has been removed from the class MoLevelColorMapping. It returned an object of an internal implementation class that has no meaning from a public api point of view.
  • The include folder MeshVizInterface has been renamed to MeshVizXLM. Any line containing #include <MeshVizInterface/...> must be replaced by #include <MeshVizXLM/...>
  • MiVolumeMeshUnstructuredIjk has been removed from the public API. There is no replacement class as long as it was not very useful. If your application was using this class, please contact-us to request some support.
  • MeshVizImpl library is not available anymore. Implementation classes it provided are now classes as a component of the demos using it. The default implementation are also provided as example in the demos.
  • The method getNewClone() from the mesh interfaces has been moved to the extracted mesh interface. As a consequence following classes will not provide the getNewClone() any more
    • MiLineMesh[Curvilinear|Regular|Unstructured]
    • MiPointMeshCurvilinear
    • MiSurfaceMesh[Curvilinear|Rectilinear|Regular|Unstructured]
    • MiVolumeMesh[Curvilinear|HexahedronIjk|Rectilinear|Regular|Unstructured|VertexHexahedronIjk]

    While the following will now provide it:

    • MeXLineMesh[Curvilinear|Unstructured]
    • MeXPointMeshCurvilinear
    • MeXSurfaceMesh[Curvilinear|Rectilinear|Regular|Unstructured]
    • MeXVolumeMeshUnstructured

    This allows the API to be clearer as long as cloning a mesh given by the application via a mesh interface does not make sense while cloning an extracted mesh computed by MeshViz xlm is obviously clear.

  • Methods getNodeName and getCellName from following class have been removed:
    • MiTopologyI
    • MiTopologyIj
    • MiTopologyIjk
    • MiHexahedronTopologyExplicitIjk

    These methods were virtual and called from the inside of Open Inventor, so it won't be a problem if one your class defines these methods. There won't be any compilation issue but as long as the code won't be called anymore, the methods can be removed from your classes too.

  • MiBoundedDataSet class has been removed from the public API. Deprecated since Open Inventor 9.3, this class was useless as no getMin/Max is necessary during any mesh extraction.

Java API

  • OpenJDK 11 is now required.
  • On Windows, you need to install Microsoft Visual C++ 2012 Update 4 Redistributable to execute an Open Inventor Java application.
  • Open Inventor Java is not available anymore on Linux 32bit.
  • On Linux 64bit, Open Inventor Java needs RHEL6 or CentOS6 run-time.
  • OpenInventor.jar has been splited into several jar files. So in your build system be sure to add the needed reference to the following new jar files :
    • com.openinventor.inventor.jar
    • com.openinventor.inventor.ui.awt.jar
    • com.openinventor.hardcopy.jar
    • com.openinventor.ivtune.jar
    • com.openinventor.meshviz.jar
    • com.openinventor.volumeviz.jar
    • com.openinventor.ldm.jar
    • com.openinventor.remoteviz.jar
    • com.openinventor.scaleviz.jar
  • packages are not available anymore. Only com.openinventor packages can be used.
  • Some deprecated code is now not generated anymore. As a consequence:
    • Any call to SoMField.get1Value(i) must be replaced by SoMField.getValueAt(i)
    • Final constant corresponding to C++ enum value are not available anymore. You must use the corresponding Enum value directly instead
    • All fromValue methods have been removed from all enums. You must use the corresponding Enum value directly instead
    • All getCoords and setCoord methods of classes SbVec* have been removed. You must replace them with call to getValue and setValue


  • If using an Open Inventor viewer, e.g. SoWinExaminerViewer, you must add a new reference named : OIV.Inventor.Win.dll
  • OIV.InventorToWpf assembly Has been renamed OIV.Inventor.Wpf. If using WPF, your project must be updated to point to this new assembly in order to be able to compile any project against Open Inventor.
  • Remove (if necessary) the reference : OIV.Inventor.SbLinear.compat
  • SbNativeArray
    • These classes, previously in namespace OIV.Inventor, have been moved to namespace OIV.Inventor.Generic.
    • More importantly, these classes are now declared as templates. This means, for example, SbNativeFloatArray must be replaced with SbNativeArray<float>. More generally SbNativeTYPEArray must be replaced with SbNativeArray<TYPE>.
  • Oiv.Inventor.SbEventHandler
    Has been removed from the public API. Instead please use Microsoft System.EventHandler<>
  • MeshVizXLM
    We no longer provide a .NET API for MeshVizXLM.
    However .NET Applications can use MeshVizXLM via the C++ API.

Because of an internal change in how C++ code is wrapped, some methods may have disappeared from the public .NET API.  It is not possible to list all of them. If you find that a method useful to you has been removed, please contact-us to request support.