Release Notes

Open Inventor® 9.7 (January 2017) 

Older release notes

The following document contains the release notes for the latest minor release 9.7 (January 2017).

The current service release is 9.7.0. See the bugs fixed section for a complete list of issues resolved for each version. Make sure to read the Compatibility Notes as well. They contain information about important changes in this release.

Finally, check the Life cycle topic for important information about Open Inventor platform support changes in upcoming release.

See below the complete list of enhancements and new features included in Open Inventor 9.7.


Compilers and Operating Systems

Visual Studio 2015 support

Starting with Open Inventor 9.7, Microsoft Visual Studio 2015 (update 2) is now officially supported for both 32 and 64 bits platforms. This support aloso requires a newer version of FLEXnet tools, and it's now mandatory to use, at least, the 11.14 version.

Please also note that because of the integration of Qt 5.6, Visual Studio 2010 is no longer supported (32 and 64 bit).

Linux

Because of the integration of Qt 5.6, the only compiler supported under linux is now GCC version 4.4.4 64bits

OS X

Open Inventor 9.7 introduces a brand new installer (.dmg file) for the C++ and Java package. For more information regarding all the details of these installers, please refer to the installation procedures (C++ - Java)

Architecture name has also changed : MacOSX is now OSX. So the OIVARCH environnement variable need to be set to arch-OSX-x86_64-clang60-release or arch-OSX-x86_64-clang60-debug.

The only supported compiler for MacOSX is now clang 6.0. Note also that all demos are available through xcode projects.

Licensing

Open Inventor 9.7 uses a new version of Flexnet tools. You must update your installation with version 11.14, which is available on our download pages (C++, Java, .NET).


Qt 5.6

Open Inventor now fully supports QT 5 and requires the version 5.6 of the well known GUI library. This new feature introduces two major changes from an application point of view

  • On OS X the introduction of Qt 5 leads us to provide a fully compatible installer allowing a fast and reliable distribution. To support such feature, Open Inventor 9.7 binaries (libraries and executable) or now built upon the RPATH mechanism. In extension, any QT application based on Open Inventor will need to use the same mechanism in its deployment process.
  • To be able to run an application using Qt 5 it's now mandatory that this application is able to find some platform specific libraries provided by Qt. When developing an Qt application based on Open Inventor the better way to initialize the path to these libraries is to write a Qt.conf file as described on this page. If, for any reason, your application cannot use this standard process, you can use the following step to allow your application to find the needed platform specific libraries:
    • In your application, before the QApplication creation, you must add the call to SbQtHelper::addPlatformPluginsPath(). This method will initialize the path to the QT platform libraries depending on your configuration and allow Qt to load properly.
    • If you intend to distribute your Qt application as a whole package with Open Inventor, it's mandatory that the call to SbQtHelper::addPlatformPluginsPath() is given, as a parameter, the path where to find the platforms directory in the package you distribute (originally found in <$OIVHOME/$OIVARCH/platforms>).

Please keep in mind that the second option does not allow any modification of the folders hierarchy of your application.


Open Inventor

Custom Nodes

  • To ease the development of complex and powerful custom nodes, we've added some new mechanisms and tools in Open Inventor 9.7:
    • SoAction::forwardTraversal (SoNode *node): This method is useful to create custom "composite" nodes implementing their behavior using a collection of other Open Inventor nodes.
    • SoNodeDenpendencies class: a simple and yet very useful helper to determine the state of the cache and of all its dependencies inside your custom node.

CAD Readers

  • CAD Readers now support PLMXLM file extension. Please note that you will need a specific license to be able to use this feature.

Viewer Components

  • Viewer components now supports Raw Stereo in Newt/AwtCanvas/Awt and Canvas/swt components. Demos available in the public directory show a new Preferences menu to activate the feature. To help you implementing the raw stereo in you own viewer, a new SoRawStereoParameters class has been added to the public API. It allows to pass stereo parameters to SoRenderAreaCore via the setStereo(SoStereoParameters parameters) function. Please note that MFC Viewer Components also provide the same level of feature. Unfortunately, a bug in Qt 5.6 prevents us to provide the Raw Stereo feature for Qt Components.
  • Seek feature has been added to all Viewer Components.
  • New Plane navigation mode has been added to all viewers component allowing to constraint the camera along a normal vector. Please note that a new NAVIGATION_MODE enum has been added to SceneExaminer class to switch between PLANE and ORBIT mode but this API will be changed in final version of Open Inventor 9.7.

New SoIndexedTriangleFanSet shape node

This shape node constructs triangle fans out of vertices located at the coordinates specified in the vertexProperty field (from SoVertexShape), or the current inherited coordinates. For optimal performance, the vertexProperty field is recommended. SoIndexedTriangleFanSet uses the indices in the coordIndex field (from SoIndexedShape) to specify the vertices of the triangle fans. An index of SO_END_FAN_INDEX (-1) indicates that the current fan has ended and the next one begins.

The vertices of the faces are transformed by the current transformation matrix. The faces are drawn with the current light model and drawing style. Treatment of the current material and normal binding is as follows:

  • PER_PART specifies a material or normal per fan. PER_FACE binding specifies a material or normal for each triangle.
  • PER_VERTEX specifies a material or normal for each vertex. The corresponding _INDEXED bindings are the same, but use the materialIndex or normalIndex indices (see SoIndexedShape). The default material binding is OVERALL. The default normal binding is PER_VERTEX_INDEXED

If any normal (or materials) are specified, Open Inventor assumes you provide the correct number of them, as indicated by the binding. You will see unexpected results if you specify fewer normal (or materials) than the shape requires. If no normal are specified, they will be generated automatically. To render triangles that are not in fans, please refer to SoIndexedTriangleSet and SoIndexedTriangleStripSet nodes.

 

New SoBillboard shape node

  • SoBillboard: because of the removal of the VRML API in Open Inventor 10, Open Inventor 9.7 introduces this new node with the exact same properties than the old SoVRMLBillboard to ease your transition to Open Inventor 10. In your application, simply parse the code and replace any occurrence of SoVRMLBillboard with SoBillboard.

VolumeViz

HeightFieldRender : Outline width and color adjustment

Available since Open Inventor 9.4 the capability to draw cell outlines offers a great visual improvement for SoHeightFieldRender rendering. In Open Inventor 9.7 it's now possible to change the color and the width of these outlines.

To achieve this, two new fields have been added to the SoHeightFieldRender class:

  • SoHeightFieldRender::cellOutlineWidth: defines the width of the cell outline. Default is 2 pixels.
  • SoHeightFieldRender::cellOutlineColor: defines the color of the cell outline. Default color is Black.

Of course value of these fields are only taken in account if SoHeightFieldRender::cellOutline is set to TRUE.

Illustration of a SoHeightFieldRender with cell outline activated, size set to 5 and color updated.
( click on image to get full resolution)

New DICOM reader

In order to improve our DICOM support, VolumeViz reader SoVRDicomFileReader has been upgraded and now uses the third party library GDCM. As a result, the number of DICOM image encoded now includes:

  • RAW
  • JPEG lossy 8 & 12 bits (ITU-T T.81, ISO/IEC IS 10918-1)
  • JPEG lossless 8-16 bits (ITU-T T.81, ISO/IEC IS 10918-1)
  • JPEG 2000 reversible & irreversible (ITU-T T.800, ISO/IEC IS 15444-1)
  • RLE
  • Deflated (compression at DICOM Dataset level)
  • JPEG-LS (ITU-T T.87, ISO/IEC IS 14495-1)

Moreover, new SoVRDicomFileReader are now able to load RGB images from a DICOM file.

Note that no additional license is required to use the upgraded reader.

Wavelet Compression

Starting with Open Inventor 9.7, VolumeVizLDM now integrates OpenJPEG library in order to be able to offer wavelet compression for LDM file. The result is a new compressor class SoJp3dDataCompressor that can be used in your custom reader if you want to implement a Jp3d capable reader.

In order to be able to generate Jp3d compressed files, LDM Converter now provides a new option to generate a Jp3d compressed LDM file instead of the classic gzip file. If you use the commande line version of the converter, you may pass the option -c jp3d to get the Jp3d compression. If you use the SoConverterParameters class, you will then need to add a call to SoConverterParameters::setCompressionName("jp3d") to activate this new compression algorithm. It supports lossless and lossy compression. Please refer to the associated documentation to get more information about the compression parameter of the SoJp3dDataCompressor. As usual, the detection of the format will be automatic when, after compression, you will load the file within an application using the SoLDMReader.

Please note also that when using Jp3d compression, you may notice that time to reach full resolution of your volume data may be a little bit longer compare to gzip compression. But the high compression rate make Jp3d compression very useful fot archiving dataset and is far more efficient if you load your datas from a limited bandwidth network.


MeshVizXLM

  • Demo directory has been slightly reorganized to be clearer than before. Here is the new folder hierarchy you will find:
    • OIVHOME/src/MeshVizXLM/data: Gather all datasets used by demos, samples and tutorials
    • OIVHOME/src/MeshVizXLM/demonstrators: Demos: EclipseMeshViz, MeshViewer, PEBIMeshViz, QuadraticWheelHexa27, Turbine
    • OIVHOME/src/MeshVizXLM/mapping: Simple demos using mapping library
    • OIVHOME/src/MeshVizXLM/mapping/tutorials: Some simple tutorials using the mapping library
    • OIVHOME/src/MeshVizXLM/extractors: Simple demos using extractor library
    • OIVHOME/src/MeshVizXLM/mesh: Class examples showing implementation of mesh interfaces
    • OIVHOME/src/MeshVizXLM/mesh/templates: Example of include showing how to implement mesh (cannot be compiled)

 

  • Access to mesh buffer: New method has been added in the extracted meshes to give an access (when available) to the internal buffers that describe the topology, the geometry and the dataset of these meshes. Starting from Open Inventor 9.7, these methods are available:

    as these new methods getBuffer return an object of type SoBufferObject, the library MeshViz Extractor now depends on the OpenInventorGL lib. Please note also that the returned SoBufferObject can be used directly into a shape.

 

  • Memory and performance improvement: This new method is now used internally and allows better performances is some cases. Following chart shows the improvement that can be observed since the introduction of the getBuffer() method for MeXTopologyExplicitI, MeXGeometry and MeXDataSet. It compares the memory consumption between Open Inventor 9.6 and 9.7 while extracting a skin from a hexaIJK mesh of type MiVolumemeshHexahedronIjk. Whatever the mesh's size, the average gain is still around 40%.

    Another chart, available at this address, shows that Action Time (time from the start of the extraction and the first render) also benefits from this new method with a reduction of the time needed to get the first frame rendered compared to Open Inventor 9.6 (in every case for the same kind of extractions). 


ImageViz

General API improvements

  • Automatic compute mode

    The computeMode field is available for any ImageViz engine filling both of the following conditions:

    • The engine works with both 2D and 3D images
    • It has a different behavior when used in a 2D and in 3D

    In previous ImageViz versions the computeMode field was set by default to MODE_2D, but this was a problem and could lead to errors when applied on a 3D image. Now the default mode is a new MODE_AUTO enumerate that chooses automatically the most suitable mode at the execution. This mode is equivalent to:

    • MODE_2D when the input image is 2D
    • MODE_3D when the input image is 3D
  • Image Interpretation The SoImageDataAdapter class contains a new field interpretation that can be set to one of the three following enumerates: VALUE, LABEL or BINARY. Please refer to the section Restriction on Input data types for more information about this new feature.
  • 3D Neighborhood management

    Most of the morphological algorithms relying on the use of a cubic structuring element allow now to select which voxels can be considered as neighbors of a central voxels. The related engines expose a new field neighborhood3d with 3 possible values:

    • CONNECTIVITY_6 : Voxels with a common face are considered connected
    • CONNECTIVITY_18: Voxels with at least one common edge are considered connected
    • CONNECTIVITY_26: Voxels with at least one common vertex are considered connected

    The default mode is CONNECTIVITY_26 corresponding to the former behavior.

  • ROI Management

    The new class SoProxyDataAdapter allows to define a Region Of Interest (ROI) on an SoImageDataAdapter class. This object can be then used as input of any ImageViz image processing engine in order to apply the corresponding algorithm only on the selected ROI. It avoids to make a copy of the selected area with an SoCropImageProcessing engine. Note that this ROI is necessarily a box aligned with the original image bounding box. This class may also be used to filter out a specific channel (e.g : extract the red component from an RGB image).

  • Image data accessors

    The SbImageDataAccessor class has been improved with some new member functions allowing to read or write data from an SoImageDataAdapter class:

    • getVoxel: returns a voxel intensity from a specific position (spatial, temporal and channel index)
    • setVoxel: writes an intensity to a specific position (spatial, temporal and channel index)
    • getRow: reads all intensities of a specific row into an array
    • setRow: writes an array of intensities at a specific row
    • getColumn: reads all intensities of a specific column into an array
    • setColumn: writes an array of intensities at a specific column

    These new features are especially useful for implementing custom engines. In addition, the SbDiscreteLineProfile class allows to extract all voxels intensities along a segment defined by 2 points. This feature can be used to draw a line profile.

Geometry And Matching: Image Registration

Some new engines allow to perform a registration between two 3D datasets:

Registration of an MRI data set (gray) on a CT data set (colored)

Image Filtering

  • Box Filter Optimization

    The SoBoxFilterProcessing engine has been rewritten allowing some strong optimizations. Following charts shows performances comparison between Open Inventor 9.6 and Open Inventor 9.7 (3D and 2D).

    Please note that now, when used with the autoScale field set to YES, the output type is no longer upgraded (ie: an 8 bits input gives now an 8 bits output). If the autoScale option is set to NO, the output type is still upgraded.

  • Non Local Means filter

    The SoNonLocalMeansFilterProcessing new engine applies an edge-preserving smoothing filter. It computes a weighted mean of a large set of pixels (search windows) around the pixel to be denoised (target pixel). The pixel weight in the search window is a function of the similarity between this pixel and the target pixel. A pixel very similar to the target pixel will be assigned to a weight close to 1. A pixel very different from the target pixel will be assigned to a weight close to 0 and will have a small impact on the final denoised value.

    Original Image (1024x1024) Square Medial Filter of size 10 NonLocal Means Filter of size 10
  • Median Filter Optimization

    The SoMedianFilterProcessing engine proposes a new field kernel type. The ITERATIVE mode enables the former mode of the median filter. This algorithm repeats iteratively a median filter on a square or cubic window with a side size of 3. This algorithm converges quickly and applying more than 3 iterations doesn’t change the result significantly. As a consequence the main drawback of this algorithm is to be ineffective when a large window size is required. The BALLS and CUBE modes perform a real median filter on the full size of the window. These modes are performed by an optimized algorithm which offers improved performances. The gain of performance is especially noteworthy in 3D case. For small kernel size in 2D, the former mode (iterative) is recommended.

    Original Image (1024x1024) Iterative median of size 20 (0.15 sec) Disk median of size 20 (0.13 sec)

     

Following charts shows a scalability comparison of median modes on a 512x512x512 3D dataset

Please note that a new parameter is exposed with this command. The default mode corresponds to the former behavior in order to preserve compatibility.

Edge Detection

Image Segmentation

  • Threshold By Criterion

    The new engine SoThresholdingByCriterionProcessing allows thresholding a grayscale image by selecting a comparison criterion as used with the SoCompareValueQuantification and SoCompareImageQuantification engines. This engine presents the benefit of defining a threshold with a single value instead of two like with the classical SoThresholdingProcessing engine.

  • New option for Automatic Thresholding

    The SoAutoThresholdingProcessing engine proposes a new field RangeMode for selecting the way to define the input range. The OTHER enumerate corresponds to the former mode which was not adapted by default when the dynamic of the input image was greater than 256 gray levels. The new mode MIN_MAX allows a default behavior working with most of the grayscale images.

  • Center Line Algorithm

    The new SoCenterLineApproximation3d engine extracts the centerlines of a 3D object. Contrarily to the existing SoSkeletonProcessing this algorithm passes at the center of the branches constituting a 3D objects and limits the generation of prunes artifacts. The number of branches to detect can be set or automatically computed. This engine produces 2 outputs

    • A SoImageDataAdapter output which represents the center lines as a set of voxels having an intensity of 1 in a binary image
    • A SoIndexedLineSet output which represents the center lines as a geometry object through a polyline shape

    Result of the centerline algorithm
    Data courtesy of Cancer Imaging Archive - Smith K, Clark K, Bennett W, Nolan T, Kirby J, Wolfsberger M, Moulton J, Vendt B, Freymann J. (2015). Data From CT_COLONOGRAPHY. The Cancer Imaging Archive. http://doi.org/10.7937/K9/TCIA.2015.NWTESAY1

Mathematical Morphology

  • Euclidean Distance Map

    The new SoEuclideanDistanceMapProcessing3d distance map engine computes a 3D distance map with the Euclidean metric whereas the former SoChamferDistanceMapProcessing3d makes an approximation with the Chamfer metric. The Euclidean metric is much more precise but is more time consuming for computation.

    Original image
    (XY view of a sphere)
    Distance map with the Chamfer metric
    (SoChamferDistanceMapProcessing3d)
    Distance map with the Euclidean metric
    (SoEuclideanDistanceMapProcessing3d)
  • Local Thickness Map

    The new SoLocalThicknessMapProcessing3d engine computes the local thickness for each voxel in a binary image, defined as the diameter of the largest ball containing the voxel and entirely inscribed in the object, following the definition of Hildebrand&Ruegsegger, J.Microscopy, 185:1, 1997.

    Result of SoLocalThicknessMapProcessing3d with TEMPERATURE color map

  • Isolated Point 3D

    The SoIsolatedPointsProcessing3d new engine extracts from a 3D binary image all object voxels having no neighbor, like SoIsolatedPointsProcessing2d already available in the previous versions.

Image Analysis

  • Image Histogram

    The SoIntensityHistogramQuantification and SoIntensityBinHistogramQuantification new engines compute the histogram of a gray level image. The first engine imposes a bin size of 1 whereas the second one allows setting a specific bin size.

  • Secondary Minor Diameter Predefined Measure

    In the SoDataMeasurePredefined class the LENGTH_3D measure, also known as Feret's longest diameter, represents the major diameter of an object. The BREADTH_3D measure is the primary minor diameter, largest diameter orthogonal to LENGTH_3D. The new measure THICKNESS_3D is the secondary minor diameter, largest diameter orthogonal to both measures LENGTH_3D and BREADTH_3D. The related THICKNESS_ORIENTATION_PHI_3D and BREADTH_ORIENTATION_THETA_3D measures express the orientation of this secondary minor diameter.

  • Integer 64 bits and Double Precision support for Analysis Measures

    Precision and capacity have been improved for large data analysis with the following predefined measurements of the SoDataMeasurePredefined class:

    • AREA_2D
    • AREA_3D
    • INTENSITY_INTEGRAL
    • SQUARE_INTENSITY_INTEGRAL
    • VOLUME_3D

Restriction on input data types

ImageViz makes a difference between gray level, label and binary images. This distinction was not visible in the public API, any of these image type was seen as a gray level image. An engine requiring a specific type used to cast automatically the input to the expected type. For instance if an engine expected a binary image as input and a 256 levels image was set, all values greater than 1 were clamped at the execution. If this behavior could be convenient at some points, it could also have some disastrous side effects leading to incomprehensible bugs. Applying an engine on an incorrect data interpretation type raises now an exception. The new interpretation field of the SoImageDataAdapter class allows to control explicitly the interpretation type (VALUE, LABEL or BINARY).

Use case: 03.1.LabelAnalysis tutorial demo : This demo loads a binary dataset from a tif file. By default a data adapter got from an image file has the interpretation field set to VALUE. Applying an SoLabelingProcessing engine directly on this data adapter would raise the exceptions below:

Inventor error: LabelingProcessing: Unable to initialize 'inObjectImage' input field with a value image. Inventor error: LabelingProcessing: Unable to initialize 'inObjectImage' input field. Inventor error: LabelingProcessing: engine cannot be computed because input and/or output are not valid.

In order to avoid exceptions and assure the code runs as before the following instruction has been added to this demo: 
imageAdapter->interpretation = SoImageDataAdapter::BINARY;

 


RemoteViz

H.264 video codec support

In order to reduce bandwidth usage and latency, H.264 video codec support has been integrated in this new version of RemoteViz. H.264 is a video codec standard using an advanced compression method which allows to obtain high-quality videos while keeping a low bit rate. It uses the Nvidia video codec SDK for video encode hardware acceleration. Indeed, NVIDIA GPUs (Kepler generation or higher) contain a dedicated accelerator to encode video at higher speeds and with a better power efficiency than CPU-based encoders.

Compared to JPEG encoding, H.264 encoded streams reduce the bandwidth usage between clients and the service by 30% for the same level of image quality and FPS. The following chart shows the bandwidth comparision between JPEG encoder and H264 encoder at constant image quality and FPS.

Please note that some hardware requirements have to be fullfiled in order to benefit from H.264 encoding.

To be able to encode using H.264, server side application must be launched on a NVIDIA Quadro, Tesla, GRID or GeForce products with Kepler, Maxwell or Pascal generation GPUs. Moreover you must install Cuda 8 Toolkit from NVIDIA. On client side application, there is no particular hardware requirement as long as the H.264 decoding is done through HTML5 Api. 

Using RemoteViz with source other than Open Inventor

Introduced in RemoteViz 9.6, the independent service mode enables to run a RemoteViz application based on your own render engine. In this new version, the previous pushFrame mechanism has been replaced by a requestedFrame mechanism. RemoteViz now requests a new frame when needed, unlike the previous pushFrame mechanism that involves generating and pushing frames that are not always sent to the client. It enables to keep a better synchronization between the render engine and the RemoteViz service.

Define bandwidth usage by connections

The JPEG encoding quality settings “InteractiveQuality” and “stillQuality” have been replaced by a new setting: “MaxBandwidth”. The JPEG quality is automatically calculated from the bandwidth and the FPS defined for the connection. The encoding settings have been moved from the removed RenderAreaSettings class to the ConnectionSettings one. Clients can now share the same view (renderArea) by using many encoders (JPEG or H.264) or many encoding settings (bandwidth and FPS).

Bandwidth calibration

RemoteViz in Open Inventor 9.7 also provides a new bandwidth calibration mechanism to allow your application to take advantage of all the potential of the used network. In a nutshell, during connection step, a calibration phase is launched to test bandwidth capability of the client application. The result of this calibration is then used to set default bandwidth value of BandwidthSettings object. Of course this value can be changed manually by using the provided API.

Still rendering enhancement

In this new version of RemoteViz the still rendering (done when there is no interaction on the scene) now use a PNG encoding (where it was previously JPEG encoding) to avoid any loss of quality.

Docker

We now provide a Docker file allowing you to run the demo server RemoteVizHelloCone in a Docker container. For more details please read $OIVHOME/src/RemoteViz/Docker/ReadMe.txt file.


Java API

  • New auditors management: introduced in Open Inventor 9.6, new generic mechanism to manage event in OIV are now available for Java API. It implies a new class, SbEventHandler, encapsulating a list of listeners that will be called when an given event occurs.

MeshViz XLM Java

Lots of new features have been added applying to the following mesh interfaces

  • Unstructured surface mesh: MiSurfaceMeshUnstructured
    • New outline extractor which handles cell ranges
      An instance of an outline extractor (MiOutlineExtractUnstructured) can now be created from MiSurfaceMeshUnstructured.
      For data mapping, MoMeshOutline node now handles MiSurfaceMeshUnstructured.
  • Curvilinear surface mesh: MiSurfaceMeshCurvilinear
    • New outline extractor which handles cell ranges
      An instance of an outline extractor (MiOutlineExtractIj) can now be created from MiSurfaceMeshCurvilinear.
      For data mapping, MoMeshOutline node now handles MiSurfaceMeshCurvilinear.
    • New MoVec3SetIj node can be used to store a vector data set for a structured surface mesh.
    • New cell extractor which handles cell ranges
      An instance of a cell extractor (MiCellExtractIj) can now be created from MiSurfaceMeshCurvilinear.
      For data mapping, MoMeshCellShape node now handles MiSurfaceMeshCurvilinear.
  • Unstructured volume mesh: MiVolumeMeshUnstructured
    • Outline extractor for unstructured volume mesh now handles cell ranges too.
  • HexahedronIJK volume mesh: MiVolumeMeshHexahedronIjk
    • Enhancement of outline extractor
      Outline extractor for HexahedronIJK mesh is now more efficient and displays all edges belonging to only one cell.
      It also handles cell ranges too.
    • Vectors representation is now possible on HexahedronIjk mesh. MoMeshVector node handles now MiVolumeMeshHexahedronIjk
    • New point probe extractor which handles cell ranges
      An instance of a point probe extractor (MiPointProbeHexahedronIjk) can now be created from MiVolumeMeshHexahedronIjk.
      For data mapping, MoMeshPointProbe node now handles MiVolumeMeshHexahedronIjk.
    • New cell extractor which handles cell ranges
      An instance of a cell extractor (MiCellExtractHexahedronIjk) can now be created from MiVolumeMeshHexahedronIjk.
      For data mapping, MoMeshCellShape node now handles MiVolumeMeshHexahedronIjk.
    • New streamlines extractor which handles cell ranges
      An instance of a streamlines extractor (MiStreamlineExtractHexahedronIjk) can now be created from MiVolumeMeshHexahedronIjk.
      For data mapping, MoMeshStreamline node now handles MiVolumeMeshHexahedronIjk.
       

    Example of a Cells extraction (MoMeshCellShape) and outline (MoMeshOutline node) on a HexahedronIJK volume mesh
    ( click on image to get full resolution)

  • VertexHexahedronIJK volume mesh: MiVolumeMeshVertexHexahedronIjk
    • New outline extractor which handles cell ranges
      An instance of an outline extractor (MiOutlineExtractIjk) can now be created from MiVolumeMeshVertexHexahedronIjk.
      For data mapping, MoMeshOutline node now handles MiVolumeMeshVertexHexahedronIjk.
    • Vectors representation is now possible on VertexHexahedronIJK mesh and MoMeshVector node also handles MiVolumeMeshVertexHexahedronIjk
    • New point probe extractor which handles cell ranges
      An instance of a point probe extractor (MiPointProbeIjk) can now be created from MiVolumeMeshVertexHexahedronIjk.
      For data mapping, MoMeshPointProbe node now handles MiVolumeMeshVertexHexahedronIjk.
    • New cell extractor which handles cell ranges
      An instance of a cell extractor (MiCellExtractIjk) can now be created from MiVolumeMeshVertexHexahedronIjk.
      For data mapping, MoMeshCellShape node now handles MiVolumeMeshVertexHexahedronIjk.
    • New streamlines extractor which handles cell ranges
      An instance of a streamlines extractor (MiStreamlineExtractIjk) can now be created from MiVolumeMeshVertexHexahedronIjk.
      For data mapping, MoMeshStreamline node now handles MiVolumeMeshVertexHexahedronIjk.
  • Examples: MeshVizXLM demos folder has been slightly reorganized. Here is the new folder hierarchy you may find in demos folder
    • meshvizxlm
      • data: contains dataset needed by all demos
      • eclipsemeshviz: EclipseMeshviz demonstrator
      • mapping: mapping examples
        • New example named vectors has been added in MeshVizXLM Demo folder.
          This example shows vectors representation on HexahedronIJK and VertexHexahedronIJK volume meshes
        • pointprobe example has been updated
          This example now shows probing on VertexHexahedronIJK mesh and HexahedronIjk volume meshes.
        • cellshape example has been updated
          This example now displays cell shapes on HexahedronIJK and VertexHexahedronIJK volume meshes and Curvilinear surface mesh.
        • streamlines example has been updated
          This example now displays streamlines on HexahedronIJK and VertexHexahedronIJK volume meshes.
      • mesh: mesh sample implementation
    • meshviz
      • graph
      • mesh

.NET API

  • As for other APIs, Viewer components using WPF now offers a new demo showing how to manage GUI integration in your own WPF viewers. The demo can be found in folder $OIVHOME/src/demos/Inventor/Gui/Wpf/WpfRenderAreaGuiIntegration