Release notes Open Inventor 10.10

The following document contains the release notes for Open Inventor 10.10 (September 2021)

See below the list of enhancements and new features included in this version.

VolumeViz

Height field rendering improvement

: Since Open Inventor 10.10, there is no more limitation in the HeightField rendering about different dataset dimensions, or tile sizes within a SoMultiDataSeparator. This means that it is now possible to render a height field if the SoHeightFieldGeometry instance and the SoHeightFieldProperty instance do not have the same dimensions and tile size.

: It is also possible to render a height field by coloring its surface according to the 3D volume properties defined by one or more SoVolumeData. The interpolation of the 3D volume property on the horizon geometry is performed on-the-fly by the GPU. No new api has been added, but instances of SoHeightFieldGeometry and SoVolumeData must be within the same SoMultiDataSeparator. For details, please refer to the "Composition with VolumeData" paragraph of SoHeightFieldRender's documentation.

A new example horizonInVolume is provided for each API and can be found in following locations:

C++: $OIVHOME/examples/source/VolumeViz/horizonInVolume
.NET: $OIVNETHOME/examples/source/VolumeViz/HorizonInVolume
Java: $OIVJHOME/examples/volumeviz/sample/horizonInVolume

: This new example highlights that it is possible to dynamically displace the horizon and instantaneously see the horizon property updated from the 3D volume, thanks to a complete GPU implementation.

The following image coming from this new example shows how the surface is rendered when it is partially inside the volume data.

GPU memory optimization when loading uniform tiles

: It is common for volume data to contain significant regions where data is uniform, for example with undefined regions. To avoid wasting memory (by storing the same value over and over) VolumeViz provides an optimization allowing to store only a single value per tile but, until now, this optimization only helped with CPU memory. Open Inventor 10.10 lifts this limitation as now uniform tiles can also be represented with a single value in GPU memory.

: Such optimization allows applications to load, with the same amount of memory, more data than before when a given dataset contains a high percentage of uniform tiles. In the same way, an application which limits the amount of loaded tiles will use less GPU memory with Open Inventor 10.10.

There are several possible benefits:

Using the same amount of GPU memory compared to previous versions, the acccuracy of the volume rendering is improved because many more non-uniform tiles can be used by the GPU to render the data. Actually for large datasets containing a high percentage of uniform tiles, the acccuracy of the rendering can be increased quite significantly.
The amount of GPU memory is much less if you limit the number of tiles used to render.
Compared to the previous version, larger volume datasets can be loaded using the same resolution and the same amount of memory.

In order to benefit from these improvements, the application must either:

Provide a volume reader inherited from SoVolumeReader that returns a tile object of type SoCpuBufferUniform for all regions having a single value. Additionally, the getTileMinMax method of this volume reader must return identical min and max values.
Use an LDM file where the min and max tile values are equal when a tile is uniform.

The image below illustrates the benefit of this optimization, with an arbitrary volume entirely composed of uniform tiles (each tile is composed of one random value). The volume on the left is rendered using Open Inventor 10.9 while the one on the right uses Open Inventor 10.10. (smaller tiles means higher resolution)

: Both volumes are rendered using the same amount of GPU memory. The loading with Open Inventor 10.9 quickly stops because the limit of the GPU memory is reached very fast, even if tiles are all uniforms. With Open Inventor 10.10, we are able to quickly reach the full resolution.

SoOrthoSliceDragger automatic highlight

: Following the improvements done on the SoTabBoxDragger in Open Inventor 10.8, the interaction with an SoOrthoSliceDragger has also been improved. When the mouse cursor moves over a slice, its border is dynamically highlighted.

: Two new fields have been added to the class SoOrthoSliceDragger: enableHighlight and highlightColor. The first one is an SoSFBool, allowing to turn on or off the feature (activated by default). The second one, an SoSFColor, is useful for customizing the color of the highlight (default color is Yelow (R=1, G=1, B=0)).

New optional border to SoOrthoSlice

: The class SoOrthoSlice has been extended to optionally render a border line at the boundary of the slice. A new field enableImage allows also to enable or disable the rendering of the image of the slice keeping just its border line. Actually the SoOrthoSlice provides now the same features as the OrthoSliceBorder which becomes obsolete. When the SoOrthoSlice is associated with an SoOrthoSliceDragger it also benefits from its new highlighting capability which leads to a change of color of the border when one interacts with the slice.

: 4 new fields have been added to the class SoOrthoSlice: borderColor, borderWidth, enableBorder and enableImage. enableBorder is equivalent to OrthoSliceBorder::border and enableImage is equivalent to OrthoSliceBorder::renderSlice.

Screen resolution culling

: Until now, the screen resolution culling policy was only defined globally for all SoDataSet through the SoLDMGlobalResourceParameters::setScreenResolutionCulling API.

: Starting with Open Inventor 10.10, the policy can be defined per SoDataSet by using the screenResolutionCullingPolicy field added to SoLDMResourceParameters class (which is associated to each SoDataSet).

: This policy allows to load only tiles for which the projection of a voxel is greater than or equal to 1 pixel on screen.

Incompatible changes in the .NET API

The obsolete public methods GetValue in the classes SoSFLDMDataTransform and SoSFLDMResourceParameters have been removed. The Value public property must be used as a replacement. For instance the following code:

    SoLDMDataTransform myDataTransform = myDataSet.dataTransform.GetValue();

Must be replaced by:

    SoLDMDataTransform myDataTransform = myDataSet.dataTransform.Value();

Even if an inherited method GetValue() still exists, using the Value property is more convenient.

Core

New capability for efficient rendering of point set

: Thanks to the use of the well known "point sprite", it is (for instance) now easily possible to customize the rendering of small textures at each point of the set.

: Point Sprites:
As explained in the OpenGL programming guide, these are essentially points rendered using a fragment shader that takes the fragment's coordinates within the point into account when running. The coordinate within the point is available in the two-dimensional vector gl_PointCoord. This variable can be used in any number of ways. Two common uses are to use it as a texture coordinate (this is the classic origin of the term point sprite), or to use it to analytically compute color or coverage.

: Program point size:
Until previous versions the size in pixels of points could only be set using the pointSize field of the class SoDrawStyle. Thanks to this feature the size of points can now be changed dynamically inside a vertex shader by writing to the gl_PointSize output variable.

A new example pointcloud is provided for each API and can be found in following locations:

C++: $OIVHOME/examples/source/Inventor/Features/PointCloud
.NET: $OIVNETHOME/examples/source/Inventor/PointCloud
Java: $OIVJHOME/examples/inventor/advanced/pointcloud

Ambient occlusion on surfaces

Ambient Occlusion (HBAO+) is now also available to any surface shapes (SoIndexedFaceSet). Two new fields have been added in the class SoEnvironment:

ambientOcclusionIntensity : controls the ambient occlusion intensity. In a nutshell, the higher the value is the darker the scene will be. Default value is 1.0
ambientOcclusionRadius : controls the radius, in world space, of the sphere in which the ambient occlusion effect is applied. Default value is 4.0

: Each field is global to the scene, meaning, modifications done to one of them is automatically applied to the same field of any instance of SoEnvironment node in the scene graph.

: You will find below illustrations showing how Ambient Occlusion helps to sublimate details in a scene and add realism to the lighting.

Ambient Occlusion Off

Ambient Occlusion On (Default Intensity & Radius)

: To learn more about Ambient Occlusion see Wikipedia: Ambient Occlusion (external resources)

Rendering performance improvement

: Rendering performance improvement (FPS) on large shapes (containing millions of triangles).

An example of improvement of the frame rate on an RTX5000 graphic board:

cad model containing several million triangles | 10.9 : 70fps | 10.10 : 140fps

Reference manual improved

: Some internal C++ namespaces have been removed from the list of public namespaces in the C++ documentation.

Viewer Components

Change in interactive mode

: Starting with Open Inventor 10.10, the interactive mode is managed automatically by SceneExaminer and the SceneOrbiter classes. Interactive mode is turned on as soon as the camera is moving and turned off after 0.5 seconds without any movement detected, even if no mouse release event occurs. This new behavior only applies on scene graph containing a node that handles the SoInteractionElement such as the SoInteractiveSwitch.

: As the new behaviour is now managed by the SceneExaminer and the SceneOrbiter classes, getInteractiveMode() and setInteractiveMode() become deprecated in RenderAreaInteractive classes, SoRenderAreaCore and SiRenderAreaInteractive. Automatic interactive mode of the SoSceneManager embeded in the RenderAreaCore is also disabled when using any RenderAreaExaminer or RenderAreaOrbiter, except for RemoteViz RenderArea for which it remains enabled.

SceneOrbiter Turntable rotation

: Starting with Open Inventor 10.10 it is now possible to manipulate a scene, inside a SceneOrbiter, using the well known Turntable rotation.

: In this mode it is not possible to see the model from arbitrary angles. In fact, the model's vertical axis is always pointing up and down on the screen as shown in illustration below (note how the green axis remains parallel to the screen's vertical border)

TURNTABLE

TRACKBALL

: Although it may feel like a constraint, it is quite convenient for some 3D scenes, where the model has an associated real-world axis for example, as it prevents from unwanted rotations. The level of constraint can be defined by calling SceneOrbiter::setConstraintLevel to better control rotations in case of fast mouse drag motions.

: The Turntable rotation is now the default mode for the SceneOrbiter. It can be changed using the SceneOrbiter::setRotationMethod() with the appropriate enum Value (TURNTABLE or TRACKBALL).

: In the same way, the scene's vertical axis can be specified using the new SceneOrbiter::setUpAxis() function with one of the value from openinventor::inventor::Axis (X|Y|Z). If used in the SceneOrbiter, the SoViewingCube will aligned its up axis with the selected one.

New render area for QML (C++)

: The class RenderAreaOrbiter is now available for the QML widgets and provides the same features and behaviours as the RenderAreaOrbiter for QT widgets. The include path folder is in <OIVHOME>/include/Inventor/ViewerComponents/Qt/QML. This new class is embeded in the lib fei_inventor_QtViewerComponents and is located in the namespace openinventor::inventor::viewercomponents::qt::qml.

: The source code of this new class is delivered in <OIVHOME>/source/Inventor/ViewerComponents/Qt/QML. A new class QtHelper is also added with 2 useful methods addPlatformPluginsPath and qtPluginsPath.

: We provide a new example QMLRenderAreaOrbiter in <OIVHOME>/examples/source/Inventor/ViewerComponents/Qt/QML.

SoViewingCube enhancements

Two new features have been added to the SoViewingCube:

It is now possible to manage an animation to make the viewing cube fading while the mouse cursor moves away from it. This animation is managed by two new fields: SoViewingCube::opacityMin and SoViewingCube::opacityMax. They define the level of opacity you want when mouse cursor is far from the SoViewingCube (opacityMin) and when it is right above it (opacityMax)
You can also add a compass inside the SoViewingCube that will be shown when the mouse cursor is far from it. Using the newly added field SoViewingCube::compass (SoSFNode) you can programatically attach a SoNode to this field so the compass will be attached to the SoViewingCube. Two examples of simple compasses are provided in $OIVHOME/examples/data/Inventor/Compass

: Pictures below show how it looks when the mouse cursor is above the SoViewingCube and when it is far from it. The compass shown in the first picture is compass-northsouth-z.iv

Mouse far from SoViewingCube (opacityMin = 0.2, opacityMax = 1.0)

Mouse above the SoViewingCube

Compatibility and dependency changes

Incompatible api changes in the SoViewingCube : With the SceneOrbiter now using the up axis, the enum Axis (X/Y/Z) has been moved to a specifc location depending on the API:
- In C++, the Axis type enum is defined in the include file Inventor\Axis.h in a namespace openinventor.inventor.
- In .NET, the Axis enum is defined in the namespace OIV.Inventor.
- In Java, the Axis enum is defined in the package com.openinventor.inventor.

In C++, the class QEventToSoEvent is now deprecated and should be replaced by the class QtEventToSoEvent.

Dependency change in C++: The viewer component libraries have been designed to be independent of the historical viewer classes and libraries. However, the Qt viewer component library was abnormally linked with the library fei_inventor_ui_qt. We have fixed that and now the lib fei_inventor_QtViewerComponents is no longer dependant on this library. However, the library fei_inventor_QtViewerComponents is now linked with several Qt5Qml* and Qt5Quick* dll. The https://developer.openinventor.com/index.php/files-redistribution/files-redistribution-10/ will be updated accordingly.

MeshViz XLM

Outline performance improvement (C++)

: Based on a new optimized algorithm, the computation of MoMeshOutline in Open Inventor 10.10 is from 8 to 10 times faster than Open Inventor 10.9 for structured reservoir grids (MiVolumeMeshHexahedronIjk or MiVolumeMeshVertexHexahedronIjk).

Some examples of improvement of the computation time on 2 different grids

Grid containing 100M cells | 10.9 : 16.4s | 10.10 : 1.58s
Grid containing 200M cells | 10.9 : 36.9s | 10.10 : 3.6s

: Note that the computation can be even faster (up to 30x faster) if, on the same grid, a skin has been extracted before.

: Note: Because of this new algorithm it is possible, in some cases (mainly when there are dead cells inside the mesh), to detect insignificant differences in extracted outline compared to Open Inventor 10.9. In any case, the output is still a list of external edges of the grid representing a kind of skeleton.

New predefined colormap (C++ & Java)

A new RAINBOW_TURBO colormap has been added to the list of predefined colormaps supported. It is very suitable to render reservoir models in the O&G domain. The new constant RAINBOW_TURBO value has been added in the enumeration PredefColorMapping of the class MoPredefinedColorMapping.

RAINBOW_TURBO colormap

RemoteViz

New npm package

: Over the past few years, npm has become an essential tool in javascript developers' workflow and is now a very convenient way to install packages and manage their dependencies automatically.

: For these reasons the RemoteViz Client of Open Inventor is now also available as npm package and all needed information can be found on this page.

: Of course Open Inventor 10.10 installers are still containing JavaScript and TypeScript files of RemoteViz Client.

Reference manual improved

: Improvement and clarification of the documentation of several RemoteViz classes in particular on the Java and .NET version.

ImageViz

New engines in .NET API

The following new engine classes have been added in the .NET API:

: The SoSFStructuredQuadrilateralMesh is also a new field class used in the new engine classes SoSurfaceUnfoldingProcessing3d, SoQuadrilateralMeshSlicerApproximation3d as an input, in the class SoPolylineExtrusionApproximation3d as an output and in the class SoSurfaceFittingApproximation3d as an input and output.

: All these classes are already available in the C++ API.

Incompatible changes in the .NET API

: The obsolete public method GetValue in the class SoSFImageDataAdapter has been removed. The Value public property must be used as a replacement. Even if an inherited method GetValue() still exists, using the Value property is more convenient.

Platforms update

New platform Ubuntu 20.04

: Open Inventor C++ & Java 10.10 are available on Ubuntu 20.04. All C++ codes are built using gcc9 compiler on this new supported platform.

Installers and packages renamed

For the sake of consistency all OpenInventor 10.10 packages (zip and exe) have been renamed. The following rule is now used:

OpenInventor[C++/Java/.NET][VersionNumber]-[headless]-[System]-[Compiler]-[Arch].

: The [compiler] is not used for the Java versions. See the download pages for details.

Licensing

Change on license activation

: Starting with OIV 10.10 release, the activation of node-locked licenses is restricted to physical machines. Only floating licenses can be used in virtual environments.