Three new nodes were added to extend VolumeViz LDM (Large Data Management) with multi-resolution rendering support to height fields, for example seismic "horizon" surfaces.
A height field is simply a regular grid of elevation values with optionally some values missing or undefined (holes). Using LDM you can now visualize multiple height fields representing hundreds of gigabytes of data at interactive frame rates.
Notes: Depending on the capabilities of the graphics board, the maximum number of triangles to be displayed for all SoHeightFieldRender nodes can be specified using the SoLDMGlobalResourceParameters::setMaxNumTriangles() method. Use a reasonable value based on the expected frame rate. On current high end graphics hardware several million triangles can typically be rendered at interactive rates.
- SoHeightFieldGeometry stores the 2D elevation values in LDM format.
SoHeightFieldGeometry inherits from and generally behaves like SoVolumeData but has an additional field:
SoSFDouble undefinedValue Specifies the value considered as undefined/missing in the elevation map.
The default is NaN (Not A Number).
- SoHeightFieldProperty stores 2D property values (in LDM format) used to color the elevation points according to the current SoTransferFunction.
SoHeightFieldProperty inherits from and behaves like SoVolumeData. The default shader supports a single SoHeightFieldProperty, but multiple SoHeightFieldProperty nodes can be combined using a custom shader program (SoVolumeShader) similar to combining multiple volumes.
- SoHeightFieldRender renders an SoHeightFieldGeometry and (optional) SoHeightFieldProperty.
SoHeightFieldRender inherits from and behaves like an SoVolumeShape.
If no SoHeightFieldProperty nodes are present in the scene graph then the elevation value is used as the the property value.
See example $OIVHOME/src/VolumeViz/examples/simpleHorizon
SoFenceSlice inherits from and generally behaves like SoSlice. This node effectively allows rendering a set of connected oblique slices. The sub-slices are defined by a 2D polyline, where each segment of the polyline is extruded along the specified axis (default Z). The defined shape is then textured using the data from the current SoVolumeData node and SoTransferFunction node. As usual the slice spans the volume (along the specified axis) but can be constrained using an SoROI node.
See example $OIVHOME/src/VolumeViz/examples/fenceSlice
The SoOrthoSlice node has a new field allowing a slice to be rendered at full resolution, without (necessarily) loading all the data in every tile containing the slice. This feature makes use of the new SoLDMDataAccess accessMode API mechanism.
When SoOrthoSlice::largeSliceSupport is set to TRUE, if all the required full resolution tiles have already been loaded, then the slice data is taken from LDM cache memory as usual. But some required tiles are not currently in memory, the slice data will be loaded directly from the volume reader (usually meaning from the file) without loading the complete tiles. This reduces disk I/O, but more importantly reduces the amount of system memory required to display the slice at full resolution, so larger (or more) slices can be displayed. The required tiles are scheduled to be loaded asynchronously in case adjacent slices are displayed later. Loading an SoOrthoSlice of size 1024x1024 from a dataset with 128x128x128 tiles would normally require loading 1024x1024x128 bytes of data from disk to memory. With the largeSliceSupport option set to true, only 1024x1024 bytes (maximum) of data will be loaded.
See example $OIVHOME/src/VolumeViz/examples/LargeSliceSupport
Using the new Computing Framework API provided by Open Inventor 8.0 to abstract device memory access, VolumeViz LDM now supports interoperability between different devices: CPU, GPU (OpenGL), or GPU (NVIDIA CUDA).
IMPORTANT NOTES: VolumeViz methods have been modified to use the new SoBufferObject API in place of C++ pointers.
In order to keep source compatibility, both versions exist but the old one have been marked as deprecated see deprecated list for a complete list.
- SoLDMDataAccess API can retrieve data from/to any supported devices
The SoLDMDataAccess API is now able to transparently transfer data from one device to another.
See examples $OIVHOME/src/VolumeViz/examples/getLDMData
- SoDataCompositor object is able to work with different buffer objects.
See example $OIVHOME/src/VolumeViz/examples/multiData/CPUDataCompose
- SoVolumeReader and all inherited readers can load data directly into a specific device memory
See example $OIVHOME/src/VolumeViz/examples/CustomReader/DataAccessCustomReader
See example $OIVHOME/src/VolumeViz/examples/CustomReader/TestLDMCustomReader
- SoLDMDataTransform: This new class replaces the previous SoLDMDataTransformFunction callback
See example $OIVHOME/src/VolumeViz/examples/dataTransform
The new abstract node class SoVolumeTransform allows you to define a custom computing operation on LDM tiles immediately before they are loaded into texture memory on the GPU. This differs from the SoLDMDataTransform class which allows you to apply a computing operation before a tile is loaded into system memory, i.e. immediately after the tile is returned from the volume reader. SoVolumeTransform could be used to apply a filter to a single volume or to generate a second volume, for example a seismic attribute, without using any additional system memory (for this case see the new SoDataSetId node).
This node applies to all VolumeViz rendered shapes, SoOrthoSlice, SoObliqueSlice, SoVolumeRender, SoVolumeSkin, SoIsoSurface, etc.
See example $OIVHOME/src/VolumeViz/examples/volumeTransform
- The SoLDMDataAccess API is now thread safe and can be used in multiple threads concurrently. SoLDMDataAccess can also now be used safely in an SoVolumeTransform::apply() function which is called during SoGLRenderAction traversal for on the fly CPU data transform. This allows the compute function to request neighboring tiles if necessary.
- The SoLDMDataAccess API has been upgraded to allow access to a subset of data within a tile without (necessarily) loading the complete tile into memory. For example, you can request a slice (data on a plane) and, for any required tiles that are not already in memory, LDM will request only the required voxels from the volume reader. This feature is used internally to implement the new SoOrthoSlice Large Slice feature.
Three access modes can be set using the new member function SoLDMDataAccess::setGetDataMode. The accessMode parameter can be:
CACHE When data is requested, the data is copied from the LDM cache (tiles in memory) if possible. If some required tiles are not in the LDM cache, LDM will load those tiles into cache, then copy the data from the cache. This is the default behavior. DIRECT When data is requested, the data is copied from the LDM cache (tiles in memory) if possible. If some required tiles are not in the LDM cache, LDM will request the data directly from the volume reader without loading any tiles in the LDM cache memory. This could potentially be slower than the previous mode, but allows getting data without loading the whole tile into memory, for example when the requested data is a slice. DIRECT_AND_PREFETCH This mode is a mix of the previous modes. When data is requested, the data is copied from the LDM cache if possible. If some required tiles are not in the LDM cache, LDM will request the data directly from the volume reader to avoid reading complete tiles immediately, but will also schedule the relevant tiles to be loaded into the LDM cache memory asynchronously. This may improve performance overall if the application is likely to load additional data from these tiles.
accessMode is particularly useful when doing pure computation on LDM data, where the data accessed for computation is not related to data needed to render objects or when randomly accessing many small chunks of data.
See example $OIVHOME/src/VolumeViz/examples/CustomReader/DataAccessCustomReader
The new SoDataSetId property node stores a data set id in the traversal state list, overriding the dataSetId field of subsequent SoDataSet nodes (e.g. SoVolumeData). This allows instancing the same SoDataSet multiple times inside a SoMultidataSeparator and assigning each instance a different data set id without duplicating any data in memory. This is useful, for example, to combine a volume with a transformed version of the volume (see the new SoVolumeTransform node).
See example $OIVHOME/src/VolumeViz/examples/volumeTransform
All VolumeViz nodes are now context safe and can be used in multiple OpenGL contexts.
This is an important feature for multi-pipe rendering see ScaleViz release notes.
Notes: Multi-Thread rendering is not yet supported.
SoLDMConverter and inherited converter class were enchanced to allow:
- LDM to LDM conversion in order to upgrade a previously converted file with new options or change previous parameters.
- Sub-resolution tile quality is now better managed to avoid bricking artifacts at lower resolution when equal resolution is set.
- Global performance optimizations with better memory management.
- SEG-Y reader optimization allowing up to 3x performance gains.
- SoOrthoSlice rendering has been reworked to use a "texture atlas" (multiple small textures are now stored on the GPU as a single large texture) increasing performance for large slices or many slices at the same time.
- SoDataRange now uses SSE instructions on X86 platforms to apply data transformations.
- SoVolumeGeometry rendering has been reworked providing up to 10x performance gains on large geometry.
- SoLDMDataAccess API has been optimized allowing much higher data access bandwidth.
- There is a new dragger node named SoOrthoSliceDragger that simplifies direct manipulation of SoOrthoSlice nodes. The new dragger is derived from SoTranslate1Dragger and automatically converts between the dragger position in 3D and the corresponding slice number in the volume. See the VolRend demo/example.
- FastEdit support has been added for VolumeViz nodes. See SoSeparator and the Users Guide for an explanation of fast editing mode.
- The LDM, Paging and "in Memory" volume loading modes were merged, enabling all the LDM rendering features to be used in any loading mode.