What's New


Open Inventor 10.11 will include all fixes available in Open Inventor 10.10.5


VolumeViz

  • Blend several datasets

    In the previous versions of OpenInventor, thanks to the class SoMultiDataSeparator(C++|Java|.Net), multiple volume datasets can be combined or blended together. However, it is not possible if the datasets have not the same extent, position, dimension and tile size. This limitation has been removed for most types of renderings volume, slice and skin.

    The default volume rendering (SoVolumeRender(C++|Java|.Net)) performs an alpha blending on all the volume datasets contained in an SoMultiDataSeparator(C++|Java|.Net). The rendering area is the union of these volume extents.

    The slices and the skin depend on a single dataset because this type of rendering is associated with properties of a volume (e.g., slice number and position in each dimension). This volume data can be specified using the new field named dataSetId available for SoOrthoSlice(C++|Java|.Net), SoObliqueSlice(C++|Java|.Net), SoFenceSlice(C++|Java|.Net), SoVolumeSkin(C++|Java|.Net) and SoROI(C++|Java|.Net).

    However, the rendering behavior can be customized using a SoVolumeShader(C++|Java|.Net). All the data contained in a SoMultiDataSeparator(C++|Java|.Net) are available through the Shader API. Thus, custom volume combinations can be implemented for volume, slice or skin renderings.

    New shader functions are available for the SoVolumeShader(C++|Java|.Net) slots, for instance, to transform texture coordinates from a volume to another. The new API is available here.

    An existing example has been updated to show one possible way of blending two volume datasets and can be found in these folders:

    • C++: $OIVHOME/examples/source/VolumeViz/multiData/AmplitudeVelocity
    • .NET: $OIVNETHOME/examples/source/VolumeViz/AmplitudeVelocity
    • Java: $OIVJHOME/examples/volumeviz/sample/amplitudeVelocity

    The following image comes from this example

    Skin of a first volume (velocity) combined with a second volume (amplitude) in the overlapping region An orthogonal slice (SoOrthoSlice(C++|Java|.Net)) attached to the second volume (amplitude) combined with the first volume (velocity) in the overlapping region
  • Support of undefined voxels

    Already available in the rendering of height fields (see SoHeightFieldGeometry(C++|Java|.Net)), the concept of undefined voxels and value has been added for volume data. Basically, an undefined voxel is not rendered and does not impact the rendering of its neighbors. Interpolation never occurs between a defined voxel and an undefined voxel.

    A voxel is considered undefined when its value equals the new field undefinedValue added in the class SoDataSet(C++|Java|.Net).

    The classes SoVolumeRender(C++|Java|.Net), SoOrthoSlice(C++|Java|.Net), SoObliqueSlice(C++|Java|.Net), SoFenceSlice(C++|Java|.Net) and SoVolumeSkin(C++|Java|.Net) take into account this new field and do not render any undefined voxels.

    Limitations :

    • The feature is not yet supported under CPU rendering
    • The fearture is, for now, only supported for byte and short (8 or 16 bit) data types
    • Handling undefined voxels can slow down the rendering of VolumeViz. This feature is particularly sensitive to the size of the rendering area containing the displayed volume
    • Combining multiple volumes can lead to undefined rendering results if the volumes do not have the same undefined value

    A new example is available to show the benefit of undefined voxels on the rendering at the boundary of a defined region. It can be found in following folders:

    • C++ : $OIVHOME/examples/source/VolumeViz/UndefinedVoxels
    • .NET : $OIVNETHOME/examples/source/VolumeViz/UndefinedVoxels
    • Java : $OIVJHOME/examples/volumeviz/sample/undefinedVoxels

    The illustration below shows the benefit of the feature. The scene contains a simple arbitrary volume clipped by an SoOrthoSlice(C++|Java|.Net) (not visible).

    On the left part, undefined voxels feature is disabled, meaning all voxels are taken in account for interpolation. This result in an unpleasant red artifact at the boundaries of the volume. On the right part, where Undefined Voxels is enabled, the result is obviously better.

  • Support of sparse data

    Open Inventor 10.11 supports sparse data, i.e., a tile can be empty and no data is stored neither in CPU memory nor in GPU memory. The rendering of regular tiles (i.e., not empty) is not impacted by an adjacent empty tile. No voxel interpolation occurs at the frontier between a normal tile and an empty tile. A tile is considered empty when the method readTile in SoVolumeReader(C++|Java|.Net) returns a null pointer, or an empty buffer.

  • Using an SoOrthoSliceDragger in your code is simpler

    In order to ease the use of an SoOrthoSliceDragger(C++|Java|.Net) in your application , the extent and dimension are now automatically retrieved from the SoVolumeData(C++|Java|.Net) on the state. Thus, it is no longer necessary to manually set the fields volumeDimension and volumeExtent which are now deprecated.


Core

  • Rendering without GPU

    This type of configuration relies on the Mesa library which uses only CPU capability. Even if the rendering is slower than using a GPU, this is a new option particularly interesting to reduce server costs. Additional details and limitations are described in the new chapter CPU rendering with Mesa 3D of the user’s guide.

  • Custom nodes and transparency
    Open Inventor 10.11 processes correctly the rendering order of a custom OpenGL node derived from SoShape(C++|Java|.Net) that needs alpha blending (i.e. non opaque object). This facilitates the migration of source code from Open Inventor 9 to Open Inventor 10, as the custom OpenGL code can be kept as is.

MeshVizXLM

  • First rendering time improved

    When you have a structured mesh without edges rendering (when MoDrawStyle::displayEdges(C++|Java) is false), the first rendering time is at least two times shorter. The most noticeable improvement occurs, for example, when displaying a MoMeshSkin(C++|Java) or a thick MoMeshSlab(C++|Java) with a cell filter from a large structured 3D mesh.

  • Picking of large surface shapes
    The time to pick and get detail information on an extracted surface has been significantly reduced on a surface containing millions of quadrangles or triangles extracted from a structured mesh. Such improvement is the consequence of new algorithm implemented on the GPU.
  • Rendering in two passes very large shapes from a mesh
    Rendering a shape extracted from a very large mesh can be quite long in particular when both the polygon faces and their outline edges must be displayed (when MoDrawStyle::displayEdges(C++|Java) and MoDrawStyle::displayFaces(C++|Java) are true).

    As of Open Inventor 10.11 the rendering can be automatically done in 2 passes in order to speed-up the initial rendering. The first pass displays the surface without the outline edges while the second one displays them later. The duration between the two passes depends on the number of extracted triangles or quadrangles : it can varies from few tenths of a second up to few seconds. The application is not sticky between the 2 passes, so that the end user can move the camera for instance. The rendering in 2 passes occurs only when there is a noticeable benefit to the end user, ie when the surface contains millions of polygons (see BeyondCell example).

  • New example BeyondCell
    A new example BeyondCell is provided in C++. It allows to visualize efficiently very large O&G reservoir grids and it introduces the concept of multiple resolutions hierarchy of the grid geometry and properties. The use of multi-resolution highlights the benefit for the end user experience.

    This example is an important step to a project that has been initially described in February 2021 here.

    The example is provided in the folder $OIVHOME/examples/source/MeshVizXLM/demonstrators/BeyondCell and all details can be found here.

    Even if a small grid reservoir dataset is provided in $OIVHOME/examples/data/MeshVizXLM/Reservoir/MultiresGrids, some larger grids are also provided and can be downloaded here. To evaluate the benefit of the multi-resolution using BeyondCell, we strongly suggest loading the larger grids. Instructions to load larger grids instead of the small embedded one are available here.

    The following image coming from BeyondCell shows a grid of 973M cells where the vertical thick slab uses a low resolution of this grid while the two others use the full resolution.

    Each sub resolution data of these reservoir grids have been generated from the initial dataset using an automatic converter tool. It uses some advanced compression technics and detects automatically the main characteristics of the geometry of the grid such as faults, undefined regions (dead cells) or pinched cells. Those characteristics are preserved in the output resolutions in order to have the highest possible rendering quality on each sub resolutions.

    The gallery below shows that despite the loss of resolution, the geometrical structure and properties of the reservoir are well kept. Here we go from full resolution to 1/8, 1/64 and finally 1/512 and still offer a very good level of interpretation.

    Full Resolution
    Resolution 1/8
    Resolution 1/64
    Resolution 1/512
    Full Resolution Resolution 1/8 Resolution 1/64 Resolution 1/512

ImageViz

  • Possibility to set padding value to SoSurfaceUnfoldingProcessing3d

    The paddingValue field has been added to the SoSurfaceUnfoldingProcessing3d(C++|.Net) engine. This parameter defines the value for output voxels having no correspondence in the input image. Its default value is 0, which is equivalent to the previous behavior.


Upcoming life cycle events

In September 2022 Open Inventor 10.12 will be released. This new version will drop the support of two currently supported platforms

  • RHEL 7 - gcc 4.8 : Both C++ and Java
  • Visual Studio 2015 : Both C++ and .Net

If this could be an issue for your application, please contact our support