The following document contains the release notes for the latest minor release 10.7.0 (September 2020).

Because Open Inventor 10 was a major step in the history of the SDK, please refer to the upgrade path documentation to get all the needed information and be sure your application is ready to be ported on this version of Open Inventor.


Important note: Since Open Inventor patch release 10.2.1, the DLLs and executables in the Open Inventor SDK are digitally signed for security. This should also avoid warning messages from anti-virus software.


See below the complete list of enhancements, new features included and old features removed in Open Inventor 10.7


Upcoming life cycle events
2020 will be the end of support for the following platforms. That means they won’t be available anymore starting Q1 2021.

  • Open Inventor 10 C++ : Qt 5.12 (replaced by Qt 5.15)
  • Open Inventor 10 Java : Oracle JDK 8 (replaced by OpenJDK)

RemoteViz : Microsoft Internet Explorer no longer supported (Microsoft Edge still supported)

By the end of Q1 2021, the following platforms will be added

  • Open Inventor 10 C++ : RHEL8 / gcc 8
  • Open Inventor Java 10 : OpenJDK will replace Oracle JDK

Inventor

  • C++ 17 Compliance

    Open Inventor 10.7 is the first 10.x official release to be fully compliant with C++ 17 Standards, meaning all our public includes can be compiled against any C++ 17 flags without generating warning

  • Performance improvements
    • The cache of an SoSwitch(C++|Java|.Net) child is preserved if this child has already been traversed once. From an application point of view it means using an SoSwitch(C++|Java|.Net) is clearly the most efficient way to temporary make a part of a scene invisible and unpickable.

      Note this optimization applies only for shapes and won't be noticeable if the disabled part of the scene contains state changes (like color or transformation)

    • The frame rate of large scene graphs has been improved when a scene contains many vertex shapes. The following charts describe the performance improvements between Open Inventor version (Higher numbers mean better performances). It shows that the Open Inventor frame rate scales better with the GPU performance, meaning that Open Inventor 10 performances are GPU dependent. On the other hand, the Open Inventor 9 frame rate does not benefit from increasing GPU performances, meaning that Open Inventor 9 performances are CPU dependent.

      Note: the frame rate is measured by the number of frame rendered per second while interacting only with the camera.

      Models details

      • Small scene Shapes 16 333 | Triangles 1 4277 229 | Lines 1 635 941
      • Medium scene Shapes 44 241 | Triangles 310 036 | Lines 453 545
      • Large Scene Shapes 283 368 | Triangles 2 949 053 | Lines 6 499 558
  • SoViewingCube(C++|Java|.Net) customization

    Three fields have been added to SoViewingCube(C++|Java|.Net) allowing to customize its faces (faceColor), edges (edgeColor) and corners (cornerColor).

    See below the result of different customizations

    Faces color customization - faceColor Edges color customization - edgeColor Corners color customization - cornerColor

    The cube can be entirely colorized uniformely or not

  • SoViewingCube(C++|Java|.Net) vertical axis definition
    A new field, upAxis, has been added to SoViewingCube(C++|Java|.Net). It defines the vertical axis of the scene.
    In its previous version the SoViewingCube(C++|Java|.Net) always considered the Y axis as the vertical one, meaning if the scene was defined with a vertical axis along another axis (Z for example), rotations could appear erratic when switching from a face to another one.

    In OpenInventor 10.7 these rotations are now driven by the upAxis value, keeping this axis always consistent when selecting a face of the viewing cube. Note that upAxis value is also taken in account for the initial rendering.

  • Behavior change

    Starting with OIV 10.7, the default orientation of the camera node is changed when the scene graph contains an SoViewingCube(C++|Java|.Net) node (note this happens automatically when using the viewer component classes SceneOrbiter or RenderAreaOrbiter).

    • Previous: Default camera view direction was 0,0,-1 (looking in the direction of -Z)
    • New: Default camera view direction is -1,-1,-1
  • Viewer components enhancement

    Starting with OpenInventor 10.7 it is now possible to set and get the SoGLRenderAction(C++|Java|.Net) used by all the render areas of the viewer components.

    The methods setGLRenderAction and getGLRenderAction have been added to classes SoOffscreenRenderArea(C++|Java|.Net), SoRenderAreaCore(C++|Java|.Net), MFC/RenderArea(C++), Qt/RenderArea(C++), Win/RenderArea(C++), swt.glcanvas.renderareas.RenderArea(Java), Wpf.RenderAreas.RenderArea(.Net).

    Thus, it is no longer necessary to inherit the render area to change its render action

  • SoClipPlane(C++|Java|.Net) performance

    SoClipPlane(C++|Java|.Net) are now cacheable. Thus, the frame rate of a scene containing a SoClipPlane(C++|Java|.Net) has been drastically improved since broken cache in previous versions leads to a long time to render each frame.

  • RenderArea Orbiter available for Java awt.glcanvas and awt.newt

    RenderAreaOrbiter is now available for awt.newt and awt.glcanvas with a new example available for both implementations. They can be found in $OIVJHOME/examples/inventor/viewercomponents/awt/[glcanvas|newt]/ renderareaorbiter

  • HighlightingStyles demo uses RenderAreaOrbiter

    The example HighlightingStyles is now based on the viewer component classes RenderAreaOrbiter and SoViewingCube(C++|Java|.Net).

    It is a good example of possible customizations of the viewing cube and also shows the easier camera manipulation and object selection allowed by the render area orbiter

  • SoOffScreenRenderArea::render() update

    Starting with Open Inventor 10.7 the render method of SoOffscreenRenderArea(C++|Java|.Net) will do nothing and, as a consequence, becomes useless.

    Please note that this is not a change of behaviour as it was previously not possible to retrieve the result of the rendering, making any call to this method completely useless