Below is a link to the "online" version of this release note that might contain more images, interactive chartings and videos.
https://developer.openinventor.com/index.php/release-notes/open-inventor-10-7-release-notes/
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
- Q4 2020 is the end of support for the following obsolete platforms. "End of support" means that, starting January 2021, new Open Inventor releases will not be built for these platforms. The current releases of Open Inventor at the end of 2020 will receive critical bug fixes on these platforms, if necessary, for one year (until the end of 2021).
- Open Inventor 10 C++ : Qt 5.12 is replaced by Qt 5.15
- Open Inventor 10 Java : Oracle JDK 8 is replaced by OpenJDK 11
- In 2021 , the following platforms will be added
- Open Inventor 10 C++ & Java: RHEL8 (gcc 8) + Ubuntu 20.04 (gcc 9)
- RemoteViz : Microsoft Internet Explorer no longer supported (Microsoft Edge still supported)
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 child is preserved if this child has already been traversed once. From an application point of view it means using an SoSwitch 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 customization
- Three fields have been added to SoViewingCube 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 vertical axis definition
- A new field, upAxis, has been added to SoViewingCube. It defines the vertical axis of the scene. In its previous version the SoViewingCube 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 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 used by all the render areas of the viewer components.
- The methods setGLRenderAction and getGLRenderAction have been added to classes SoOffscreenRenderArea, SoRenderAreaCore, 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 performance
- SoClipPlane are now cacheable. Thus, the frame rate of a scene containing a SoClipPlane 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.
- 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 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