The following document contains the release notes for Open Inventor 10.12 (September 2022)
See below the list of enhancements and new features included in this version.
Open Inventor 10.12 includes all fixes available in
Open Inventor 10.11.3
- In the previous versions of Open Inventor, VolumeViz has been extended by the capability to blend multiple datasets whatever their extent or dimension. For instance when drawing an ortho slice of a volume data V1, it is possible to blend the voxels of V1 with the voxels of a another volume data V2 even if V1 and V2 don't have the same extent or dimension. The ortho slice is obviously constrained in the volume extent of V1. It is also possible to blend V1 and V2 using SoVolumeRender but the rendering was done in the union of the extents of the 2 volumes.
- Starting with this new version, it is possible to specify on which volume extent the volume rendering must be constrained. A new multiple-field dataSetIds is added in the class SoVolumeRender. If dataSetIds contains a single id, the rendering is done in the volume extent of the selected volume. If dataSetIds contains 2 ids, the volume rendering is done in the union of the 2 volumes data selected. etc...
- An existing example has been updated to demonstrate how the volume rendering can be constrained in one of the two volumes.
- C++: $OIVHOME/examples/source/VolumeViz/multiData/AmplitudeVelocity
- .NET: $OIVNETHOME/examples/source/VolumeViz/AmplitudeVelocity
- Java: $OIVJHOME/examples/volumeviz/sample/amplitudeVelocity
- The following images come from this example, and show the 3 possibilities to blend two volume data.
Volume rendering in volume 1
|
Volume rendering in volume 2
|
Volume rendering in both volumes
|
- The rendering performances of SoVolumeRender have been significantly improved in Open Inventor 10.12 when different datasets are blended. A ratio x3 of framerate improvement (compared with 10.11) can be quite easily observed.
- Since Open Inventor 10.11, it is possible to handle undefined voxels in a volume data. This feature has been extended:
- Undefined values can be set on a volume data of type float. It was not possible in the previous version, but this limitation is now removed.
- VolumeViz is now able to blend multiple volumes data whose SoDataSet::undefinedValue fields differ. In the previous version the volume rendering was undetermined when combining multiple volumes that did not have the same SoDataSet::undefinedValue. This limitation has been fixed, thus each volume voxel whose value is undefined is considered as fully transparent as expected.
- The enumeration SoVolumeRender::RenderMode has been extended with 4 new values.
- MAX_INTENSITY_DIFFERENCE_ACCUMULATION
- INTENSITY_DIFFERENCE_ACCUMULATION
- MAX_GRADIENT_DIFFERENCE_ACCUMULATION
- GRADIENT_DIFFERENCE_ACCUMULATION
- The first one is also known as MIDA. This new mode and the other new accumulation modes help to highlight features in a volume data without specifying complex transfer function.
- An existing example has been updated in which the new MIDA mode can be selected.
- C++: $OIVHOME/examples/source/Medical/Rendering/Visualization/medicalMIP
- .NET: $OIVNETHOME/examples/source/Medical/Rendering/Visualization/MedicalMIP
- Java: $OIVJHOME/examples/medical/rendering/visualization/medicalmip
- A new example has been added to highlight the benefits of those new render mode on a well know mechanical dataset.
- C++: $OIVHOME/examples/source/VolumeViz/renderModes
- .NET: $OIVNETHOME/examples/source/VolumeViz/RenderModes
- Java: $OIVJHOME/examples/volumeviz/sample/renderModes
- You will find below illustrations showing how MIDA can easily highlight some internal features in this volume compared to the classical volume rendering mode.
-
VOLUME_RENDERING mode
|
MAX_INTENSITY_DIFFERENCE_ACCUMULATION mode
|
- Loading data of VolumeViz is more efficient in this new version because it ensures the method SoVolumeReader::getTileMinMax is only called once per loaded tile. In the previous versions, this method could be called many times which could mean prefetching the same data tile several times depending on the reader implementation. Data loading performance could be really impacted in a cloud environment where data are not on premise.
- On previous versions, the loading progression of the data was only tracked when doing volume rendering in fixedResolution mode. Thus it was only possible to implement a progress bar if SoLDMResourceParameters::fixedResolution was TRUE. That was a strong limitation but it has been removed starting with Open Inventor 10.12. Now, the loading progression is also tracked in non fixed resolution, thus a progress bar can be used in all cases. Note that the loading progression is completed when all needed 3D tiles are uploaded on the GPU, thus when the volume rendering does not update any longer the render area. Some additional detail can be found in the documentation of SoVolumeRender::setRenderProgress.
- The C++ example VolRend has been updated and it uses now a progress bar attached to an SoVolumeRender. See $OIVHOME/examples/source/VolumeViz/VolRend
-
progress bar in VolRend showing a state where 661 out of 1176 tiles are loaded
|
- Compute shaders are general-purpose shaders that are not part of the normal rendering pipeline. They are used for GPGPU programming and benefit from the faster capability of GPUs to perform floating-point calculations compared to CPUs. See Compute Shader for detail.
- Starting with Open Inventor 10.12 compute shaders can be easily used thanks to the following new API:
- Limitation: Compute shaders can't yet be used by VolumeViz.
- The fast editing is a feature defining a part of the scene graph that is being edited/modified interactivly and whose rendering performances intend to be independant of the rest of the scene. The fast editing is defined by the field SoSeparator::fastEditing. Several latencies have been removed in Open Inventor 10.12, thus the fast editing is really fast now.
- The rendering performances have been significantly improved when using multiple viewers at the same time.
- The time of the first skin extraction has been significantly reduced in Java thanks to an efficient parallel algorithm on structured IJK grids. The first extraction corresponds to the extraction when a mesh is given the first time to the skin extractor or when the topology of the mesh has been changed. See MoMeshSkin or MiSkinExtractHexahedronIjk for detail. The MoMeshSlab class benefits also from this improvement.
- As the new parallel algorithms can use multiple threads, the implementation of some mesh interface methods must be thread-safe. Thus it may require some modification in your code. The methods that must be thread-safe as of Open Inventor 10.12 are:
- The way those methods are implemented is critical for performance. Any inefficient implementation may impact very significantly the duration of the skin or slab extractions. For instance, using a mutex to ensure a thread-safe code is in general not efficient.
- This new MeshViz XLM C++ example introduced in previous version is now moved in a separate package with a separate download page coming soon. This new example is also available in Java and will be provided on demand.
- A new converter tool ReShrink is available as a complement to BeyondCell. This tool can convert an Eclipse grid files (GRDECL) into multi resolution grid files that can be read by BeyondCell. It will allow to demonstrate BeyondCell using your reservoir data file. A dedicated web page introducing BeyondCell and ReShrink is coming soon.
- The following platforms are no longer provided starting with Open Inventor 10.12:
- C++: VisualStudio 2015 and RHEL7
- .NET: framework 4.6.1
- Java: RHEL7
- In previous versions, Open Inventor proposed the concept of bundled license for the Medical market. Open Inventor Medical Edition(s) offered several optional extensions (ImageViz and VolumeViz and optionaly RemoteViz) that were bundled with Open Inventor, plus some specific examples for the medical imaging market. The Medical Editions licenses are no longer available and are replaced by a set of licenses providing at least an equivalent level of functionality. As usual, these new licenses will be sent automatically if you are under maintenance.
- In 2023, we plan to drop the version Ubuntu 18.04. If this could be an issue for your application, please contact our support.