SoGzipDataCompressor and SoJpegDataCompressor now allow the user to specify a compression level through their respective setCompressionLevel methods.
The level of compression can also be set for the LDM converter using the new -l command line option.
The new environment variable IVVR_FIRST_RESERVED_TEXTURE_UNIT allows you to specify which texture units will be used by predefined VolumeViz Shaders. If redefined this will affect all the SoVolumeShader derived nodes :
You can retrieve this value using the SoVolumeShader::getNumReservedTextures() method.
- SoVolumeRenderingQuality
- SoVolumeIsoSurface
- SoVolumeClippingGroup
You can now disable color interpolation in the standard VolumeViz fragment shaders using the new field SoVolumerenderingQuality::colorInterpolation.
If set to FALSE, interpolation is not done on data values used to access the colormap. (Interpolation is still done when computing the gradient for lighting.) This may be used to render segmented data sets where interpolation is not appropriate. The default is TRUE.
No new features were added. See the fixed bugs section.
- Amira Mesh LDM reader now supports binary little endian format
- Better SEG-Y 2D LDM reader support
A set of three demos are now provided to demonstrate interoperability between VolumeViz/LDM and Nvidia CUDA GPU computing modules.
- cudaComputeSlice demo shows on-demand slice attribute computing using LDM getDataAccess method, with direct mapping of the CUDA result inside an Open Inventor Texture Object by using the EXPERIMENTAL class SoCudaRenderer.
- cudaComputeVolume demo shows volume attribute computing by using a simple implementation of a CUDA LDM reader. It supports multiple CPU or CUDA devices. Note: it is limited to input volumes that fit entirely in the GPU memory.
- cudaComputeBatch demo demonstrates LDM to LDM computing using the SoLDMWriter to create a new volume on disk containing the result of an attribute computation using the GPU through CUDA.
See $OIVHOME/src/VolumeViz/contrib/cudaCompute
This demo provides a basic SEG-Y 2D viewer example using Open Inventor and VolumeViz LDM, including:
- Multiple SEGY-2D Slices
- 3D Horizon display
- 3D wiggle trace and variable area display
See $OIVHOME/src/VolumeViz/contrib/SegY-2D
The SoVolumeRender node now supports projected volume rendering, for example rendering a volume defined on a grid of latitude / longitude coordinates. Projection is enabled by adding an SoProjection node before the SoVolumeRender node (see SoProjection for more information about supported coordinate systems, ellipsoids and map projections). The projection quality versus speed ratio can be controlled using the new projectedTileSubdivision field that defines how often each tile's geometry will be subdivided when projected. Volume projection works with both regular and rectilinear (non-uniform voxel spacing) grids.
Notes: Projection is incompatible with VolumeRenderingQuality node. and requires LDM culling options to be disabled.See $OIVHOME/src/VolumeViz/examples/volumeProjection
SoLDMDataAccess now provides two methods (synchronous and asynchronous) specifically optimized for accessing the data in a single "trace" in a seismic data volume. A "trace" is a single row of voxel values along the volume X axis. In other words, a special case of the getDataLine methods where the line is assumed to be aligned with the volume X axis. A trace is specified by its YZ coordinate in voxel units.
Note: The same optimization has been added to the getDataLine API for the case where the line is parallel to the volume X axis.
- SoLDMDataAccess::getDataTrace
- SoLDMDataAccess::requestDataTrace
A new LDM Programming Guide for data management is now available to explain and demonstrate how to efficiently
- Load LDM data using synchronous and asynchronous calls
- Create a new LDM data file on disk
- Create a temporary LDM volume in memory
PDF document available in $OIVHOME/src/VolumeViz/Compute/PG-DataManagementVolVizLDM.pdf
Example in $OIVHOME/src/VolumeViz/Compute
SoConverter now provides a new algorithm for computing values in lower resolution (subsampled) tiles during LDM conversion and a new option (-s n) to specify which method to use. If n = 0, the default method (decimation) is used. If n > 0, a weighted average algorithm is used which combines a voxel (weighted by n) with its six nearest neighbors.
The performance of SoLDMWriter::writeSubVolume has been significantly improved in some cases. Two new parameters (with default values) have been added to this method.
If the doLowerResolution parameter is true (the default), writeSubVolume now builds the lower resolution tiles immediately. This can be significantly faster than building them in the finish() method, because the full resolution data is already in memory. To take full advantage of this feature the subvolume should include blocks of eight tiles that can be combined to form lower resolution tiles. If doLowerResolution is false, the lower resolution tiles are not generated during this call, but can still be generated later if the finish() method is called with &B doMultiResolution @b set to true.
If the doOverlappingTiles parameter is true (the default) then all tiles that intersect the subvolume to any extent will be written. This allows you to write arbitrary subvolumes. For example, you can compute using non-overlapping subvolumes regardless of what the tile overlap setting is for that volume. However if tiles overlap (overlap > 0) it may require more read/write operations (and therefore be slower) than expected. If you want to write subvolumes that correspond exactly to tile boundaries (and handle the overlap yourself), you can now set doOverlappingTiles to false. In this case tiles that intersect the subvolume by only the tile overlap (or less) are not considered intersecting.
SoLDMTopoOctree is a utility class that provides information about the LDM topology for a given dataset, based on the dataset dimensions. For example you can query the ID of the tile that contains a specified voxel/cell in the data set and you can query the extent of a specified tile in voxel/cell coordinates.
Additional methods are now deprecated and replaced by Open Inventor fields. Fields have the advantage that they are saved in Open Inventor format files.
- In SoVolumeData
NEW FIELD OLD METHOD data (set/get)VolumeData
- In SoVolumeRender
NEW FIELD OLD METHOD fixedNumSlicesInRoi new features projectedTileSubdivision new features
No new feature was added. See the fixed bugs section.
For each existing SoLDMDataAccess::getData() method, an asynchronous version has been added with the new methods requestData() and getRequestedData(). This new feature optimizes the use of LDM for computation because computing and loading can be done in parallel.
See $OIVHOME/src/VolumeViz/examples/getLDMData/asyncGetDataBox.cxx.
The new class SoLDMWriter allows an application to load or compute portions of a volume in any order and any convenient internal format, then write the volume in LDM format. The application can pass tiles or arbitrary regions of full resolution data to the writer in any order. When the writer is closed it can optionally invoke the converter and generate the lower resolution levels.
See $OIVHOME/src/VolumeViz/LDMWriter.
The previous design (up to VolumeViz 6.1) for support of multiple data sets had some limitations for performance and evolution. Although compatibility has been kept, we strongly recommend that you use the new SoMultiDataSeparator node to combine multiple data sets.
Rectilinear grid support allows non-uniform voxel spacing on each axis of the volume. The AmiraMesh reader (.am file), the in-memory reader, and the LDM reader now support rectilinear coordinates. New tags in the LDM file header allow you to to specify rectilinear coordinates (i.e., <RectilinearMapping> and </RectilinearMapping>).
The new options -c <Compression Type> and -l <Compression Level> can be used with the SoLDMConverter to specify the compression type and the compression level. Compressed data uses less disk space and can be loaded faster (fewer bytes to move). Currently gzip and jpeg compression is available. The effectiveness of compression depends on the nature of the data. By subclassing SoDataCompressor, you can add support for additional compression types.
The new argument <Border Size> to the -b option enables you to specify a border size > 1. In order to avoid discontinuity artifacts with lighted volume rendering or with bump mapped slices, a border size of 3 should be specified.
Volume rendering supports a variety of new different techniques in order to improve performance:
- Early Z: Stop computing pixels that are hidden by fully opaque pixels. This can be very efficient when a lot of slices are used and when complex shaders are applied (lighted volume rendering...). See SoVolumeRender::useEarlyZ for details.
- Slice geometry on GPU: Slice vertices for volume rendering are generated by the GPU instead of the CPU, improving performance for large numbers of slices and for tile subdivision. See SoVolumeRender::gpuVertexGen for details.
- Tile subdivision: Fully transparent sub-tiles are not rendered, increasing the speed of the rendering (when the volume has significant transparent regions). See SoVolumeRender::subdivideTile for details.
- New low resolution mode allows reducing the screen resolution of the volume while the camera is moving. See SoVolumeRender::lowResMode for details.
The following new rendering effects has been added:
- Edge coloring: Enables you to color edges based on the gradient direction. See SoVolumeRenderingQuality::edgeColoring for details.
- 2D edge detection: A 2D edge detection algorithm is used to highlight edges of the rendered volume image. See SoVolumeRenderingQuality::edgeDetect2D for details.
- Boundary opacity: Increases the opacity of boundaries based on the magnitude of the gradient. See SoVolumeRenderingQuality::boundaryOpacity for details.
- Gradient quality: Provides different methods for computing the gradient (normal) used when the rendering is lighted. See SoVolumeRenderingQuality::gradientQuality for details.
- Jittering effect: Decreases slice edge artifacts when few slices are displayed. See SoVolumeRenderingQuality::jittering for details.
- Lighting model: It is now possible to choose between the Open Inventor 6 lighting mode or the full OpenGL lighting model. The new OpenGL lighting model allows a better integration of the lighted volume with the rest of the scene. See SoVolumeRenderingQuality::lightingModel.
- Cubic interpolation to get a smooth rendering. See SoVolumeRenderingQuality::cubicInterpolation.
- Faux shading: Modifies color values adjacent to opacity changes in the color map. See SoTransferFunction.
All the previous techniques can be combined together.
Additionally, the previous limitation on the number of slices used for volume rendering has been raised. Increasing the number of slices increases significantly the global image quality of the volume rendering.
Tile loading from disk to main memory and from main memory has been significantly improved. The consequence is that high resolution rendering is obtained more quickly. Streaming SIMD Extensions instructions (SSE) are used in these optimizations.
A new interpolation type (MULTISAMPLE_12) is available for 2D slices and volume skin which provides much higher quality images than linear interpolation. See SoVolumeShape::Interpolation for details.
There are now two ways to specify volume clipping:
- Arbitrary volume clipping: Clip voxels of volume rendering by an arbitrary geometry forming a 3D closed volume. See SoVolumeClippingGroup for details.
- Surface volume clipping: Clip voxels of volume rendering against a surface defined by a uniform grid of height values. For example, a seismic horizon surface. See SoUniformGridClipping for details.
Volume clipping applies to all volume rendering nodes.
Prior to Open Inventor 7.0, it was not possible to have SoVolumeRenderingQuality and SoVolumeIsosurface apply to the same SoVolumeRender node. This restriction has been lifted.
The LDM core has been re-factored to support multiple extensions such as ReservoirViz. Consequently some headers file which are common to multiple extensions (and which existed in previous releases) have been moved to the directory $OIVHOME/include/LDM. For instance SoROI.h has been moved from $OIVHOME/include/VolumeViz/nodes/SoROI.h to $OIVHOME/include/LDM/nodes/SoROI.h. Another consequence is that the class SoVolumeData now inherits from the new SoDataSet class which is a generic class for all LDM data sets. Upward compatibility has been kept, so no code changes are required.
Numerous methods are now deprecated and replaced by Open Inventor fields. Fields have the advantage that they are saved in Open Inventor format files.
- In SoTransferFunction
NEW FIELD OLD METHOD minValue and maxValue reMap - In SoVolumeShader
NEW FIELD OLD METHOD forVolumeOnly setForVolumeOnly - In SoLDMResourceParameters
NEW FIELD(S) OLD METHOD(S) maxMainMemory (set/get)MaxMainMemory maxTilesInMainMem (set/get)MaxTilesInMainMem loadPolicy (set/get)LoadPolicy loadNotificationRate (set/get)LoadNotificationRate maxTexMemory (set/get)MaxTexMemory maxTilesInTexMem (set/get)MaxTilesInTexMem tex3LoadRate (set/get)Tex3LoadRate max2DTextures (set/get)Max2DTextures tex2LoadRate (set/get)Tex2LoadRate minResolutionThreshold (set/get)MinResolutionThreshold maxResolutionThreshold (set/get)MaxResolutionThreshold tileDimension (set/get)TileSize fixedParams fixParams and isParamsFixed overlapping (set/get)Overlapping tileHalfLife (set/get)TileHalfLife fixedResolution disableFixedResolutionMode and isFixedResolutionMode resolution enableFixedResolutionMode and getFixedResolution
The volRend demonstration program has been updated to expose the new features described above. New color maps have been added, particularly those useful for seismic data.
The support of VolumePro boards from TeraRecon has been dropped.
Expanded Capabilities
The SEGY file reader (SoVRSegyFileReader) has been greatly enhanced to allow more flexibility in reading SEGY files and to return more information extracted from the file.
For example, you can now specify the byte position of fields in the trace header. If you know the correct values, and the file is not loading correctly, you can specify the header values to use.
You can now also query additional info from the file. For example, the inline, crossline, and time ranges, as well as the actual coordinates of the seismic survey.
The new sample $OIVHOME/src/VolumeViz/Converters/SegY illustrates these improvements.
Methods Are Now Virtual (added in OIV 6.0.3)
In order to facilitate subclassing, the SoVRSegyFileReader methods have been made virtual. This makes it easier to extend/customize the functionality while also allowing re-use of some of the existing methods. (Enhancement request #1657)
Save Settings
It is now possible to save certain parameter settings for re-use the next time VolRend is started. This is accomplished using the new Save settings filename box at the bottom of the Region of Interest tab. The settings are saved in oiv.cfg by default. For information about the parameters, see $OIVHOME/src/src/VolumeViz/VolRend/ReadMe.txt.
Volume Scaling
New Volume Scale Factor sliders allow you to adjust the shape of a volume by scaling it along its X, Y, and Z axes. A reset button sets the scale factors all back to 1.0. These new controls appear at the bottom of Volrend's Geometry Control tab.
Some features have been added to VolumeViz to facilitate combined computation and rendering in shaders. For example, applications working with seismic data may wish to do computations such as NMO correction and horizon flattening on the GPU. Doing these computations "on the fly", using shaders, allows parameters to be modified interactively and offloads work from the CPU.
- VolumeViz automatically sets the GL_OBJECT_PLANE values in texture unit 1 to allow vertex shaders to compute texture coordinates relative to the entire volume. These texture coordinates allow fragment shaders to determine the absolute position of a voxel in the volume. This could be used, for example, to get the time value associated with a voxel in a seismic data set. A new utility function, VVizTexGenVol, is provided for vertex shaders to compute these texture coordinates. Note: The GL_OBJECT_PLANE values in texture unit 0 allow computing texture coordinates relative to the current tile. These texture coordinates are used for rendering using the data texture loaded for the current tile.
- New utility function provided for vertex shaders: vec3 VVizTexGenVol( vec4 vertex )
Computes texture coordinates using planes defined by VolumeViz in texture unit 1. These texture coordinates are relative to the entire volume and may be used in a fragment shader when the position of the voxel in the volume is needed.
Note: This function is not called by the default VolumeViz vertex shader.
- New uniform variables provided for vertex and fragment shaders:
- VVizVolumeDimensions: vec3 containing volume dimensions in voxels
- VVizTileDimensions: vec3 containing tile dimensions in voxels
- VVizTileMinIJK: vec3 containing current tile minimum coordinate in voxels
- VVizTileMaxIJK: vec3 containing current tile maximum coordinate in voxels
- VVizOrthoSliceAxis: int containing 0 for X axis, 1 for Y axis, 2 for Z axis (only set by SoOrthoSlice)
SoVolumeGroup now supports SoVolumeShader correctly. Until 6.0.3, it was not possible to combine multiple volumes with applying a SoVolumeShader (isosurface, lighting, and preintegrated).
Here are highlights of the new features of VolumeViz 6.0 and VolumeVizLDM 6.0:Performance improvements
- (LDM) Multi-threaded tile loading
- (LDM) Automatic tile pre-fetching
- (LDM) LDM for cluster rendering
- (LDM) LDM converter optimization
- Volume geometry faster for large surfaces
Rendering improvements
- Render to floating point RGBA buffer
- Load data and colormap in deeper textures
- Data min/max for transfer function
- Bump mapping effect on slices and skins
- Lighted volume rendering
- Isosurface rendering
- Pre-integrated volume rendering
- Application-defined shader programs
General
Each of these items, as well as many others, are discussed in greater detail below.
- Multi-data support -- (LDM) data combining, (LDM) data transforming, render combining
- Trilinear interpolation for ObliqueSlice
- All dimensions are 32-bit values
- SEGY reader enhancements including data conversion, debug and dump flags
- Enhancements to VolumePro support
- (LDM) Weight property node
- (LDM) Get data along polyline
- (LDM) Better support for thin volumes
- (LDM) Loading status callback
- (LDM) Screen resolution culling
- (LDM) Stop conversion process, save conversion progress
- (LDM) Support for custom tags in LDM header
- VolRend demo program updated
VolumeViz now has improved performance in various areas:
- (LDM) Multi-threaded tile loading allows much faster loading from disk, especially on multi-CPU and RAID disk machines. Applications can specify the number of threads. See SoVolumeRendering.
- (LDM) Automatic tile pre-fetching based on distance to geometry/ROI increases the likelihood that the data needed will already be in memory, when, for instance, moving a slice. This means that the user sees a higher resolution image when moving a slice.
- (LDM) VolumeVizLDM cluster rendering support. When using the new ScaleViz extension, render nodes load only the data and textures needed for their own view frustum, effectively increasing total system and texture memory.
- (LDM) The LDM converter can now take advantage of a cluster environment, allowing faster conversion of extremely large volumes. To enable the distributed converter, use the -D command-line option of SoLDMConverter. See SoLDMConverter for more details.
NOTE: To use this feature, you must have a VolumeVizLDM license. Its "number of nodes" field indicates the maximum number of cluster nodes that can be used during the LDM conversion.
- Improved performance of volume geometry allows mapping of volume data onto large surfaces efficiently. For example, SoVolumeIndexedFaceSet.
VolumeViz 6.0 provides the following rendering improvements:
- Support for floating point RGBA buffers was added in Open Inventor. (See, for instance, SoWinRenderArea::setFloatingColorBuffer.) In some cases, the overall rendering quality of your volume can be improved by rendering to a floating point RGBA buffer.
For example, if you have a very large volume with low opacity values, it's possible that the image could be incorrect due to loss of precision in accumulating alpha values. With a floating point RGBA buffer, these accumulation errors are reduced.
- 12-bit indexed textures are now supported. This allows you to load data and color maps into deeper textures (previously only 8-bit textures were supported). See the texturePrecision field of SoVolumeData.
- The new SoDataRange node allows you to map a sub-range of the data onto the full colormap. This was enhancement request 929.
- Bump mapping on slices and skins. This rendering technique emphasizes gradient changes in the data on the slice or the skin. It is controlled by the enableBumpMapping and bumpScale fields of SoObliqueSlice, SoOrthoSlice, and SoVolumeSkin.
NOTE: Requires programmable shader support in the graphics hardware.
- Interactive speed lighting on volume rendering. That is, you can now move the light interactively. Previously it could be very slow to change the position of the light.
NOTE: Requires programmable shader support in the graphics hardware.
- Isosurface rendering (SoVolumeIsosurface). The SoVolumeRender node can now render isosurfaces instead of volume rendering. Isosurfaces are computed in the GPU, not the CPU. This implies that the actual triangles are not available to the application as they would be in, for example, MeshViz surfaces. However, as a result, isovalues can be changed interactively.
NOTE: Requires programmable shader support in the graphics hardware.
- Pre-integrated volume rendering (SoVolumeRenderingQuality). The pre-integrated mode is useful because it usually provides much higher image quality for the same number of slices. It is also useful when the transfer function has a lot of fast variations, i.e., the color changes very rapidly.
NOTE: Requires programmable shader support in the graphics hardware.
- You can use the new SoVolumeShader node to provide your own shader programs for volume rendering. Some useful utility functions are provided in GLSL.
General enhancements include:
- Multiple data set support:
- (LDM) Data combining to apply an operator to compose several volumes in one using the new SoDataCompositor node. Some predefined operators are supplied, or you can define your own.
- (LDM) Data transforming to calculate attributes on the fly. See SoVolumeData::setLDMDataTransformCB().
- Render combining to manage and combine the textures of multiple volumes with multiple transfer functions. See SoVolumeShader.
- Trilinear interpolation on oblique slices. There is now an option to select trilinear interpolation which produces more accurate results (at a slight cost in performance). See SoObliqueSlice.
- All VolumeViz dimensions are now 32 bits to remove the limit on extremely large volumes. For details, see "New Methods and Fields Added to Allow Larger Volume Dimensions" below.
- SEGY reader enhancements are discussed in their own section, "SEGY Reader Enhancements", below.
- The enhancements to VolumePro support are discussed below in "VolumePro Data Loading is Now Integrated with LDM" and "Improved VolumePro Support in VolumeViz".
- (LDM) New weight property node to assign a priority per node. LDM will load higher resolution tiles based on this priority, i.e., high priority nodes first. See SoGeometryPriority.
- (LDM) Ability to get data along polyline (e.g., a well bore). A new getData method was added to SoVolumeData::LDMDataAccess to allow the retrieval of volume data along an arbitrary polyline within the volume. It returns a DataInfoPolyLine object. See SoVolumeData for details.
- (LDM) Improved support for thin volumes (e.g., 1 voxel deep). In other words, if one of the volume dimensions is less than the tile size, VolumeViz will automatically reduce the tile size in that dimension.
- (LDM) LDM loading status callback.
This allows the application to know and optionally indicate to the user when LDM is loading data. Of particular interest is that it allows you to know when LDM is finished refining the data. See SoVolumeRendering::setLoadCB().
This was enhancement request 1088.
- (LDM) Screen resolution culling. This means that LDM will not load higher resolution data if more than one voxel would project to the same pixel on the screen. This may reduce the amount of data that needs to be loaded.
See the setScreenResolutionCulling method of SoVolumeRendering.
- (LDM) Ability to stop LDM conversion process and save conversion progress. This allows you to start and restart visualizing an incompletely converted data set. See SoLDMConverter.
- (LDM) Support for custom tags in LDM header. See "SoVRLdmReader Allows Use of Custom XML Tags in LDM File Header".
- The VolRend demo ($OIVHOME/src/VolumeViz/VolRend) has been extensively updated to show off many new enhancements in Open Inventor as well as VolumeViz (and VolumeVizLDM). Updates include:
- 16-bit floating point rendering. This is useful to avoid saturation when working with a large number of transparent slices
- Bump mapping on slices
- Lighting
- Pre-integrated rendering
- Loading status display
- Correct use of clipping plane below an SoVolumeGroup. This was enhancement request 1115.
- You can now use clipping planes with SoVolumeGeometry node. This was enhancement request 1383.
- alphaUse and composition fields added to SoVolumeSkin. This was enhancement request 947.
- composition field added to SoOrthoSlice (enhancement request 1023) and to SoObliqueSlice (enhancement request 1350). See below for details.
- Correct lighting and view-aligned slices in case of left-handed coordinate system.
- useExtendedData field added to SoVolumeData allows slice roaming performance to be approximately the same along each axis.
- New file reader, SoVRRasterStackReader, for reading stacks of raster images.
- The LDM converter (SoLdmConverter) now calls the method getNumSignificantBits. This was enhancement request 1032.
In several classes, new methods were added that use Sbxxx3i32 instead of Sbxxx3s in the calling sequence. This allows larger volume dimensions to be specified. For example,
OLD: SoVolumeData* subSetting( const SbBox3s& region )
NEW: SoVolumeData* subSetting( const SbBox3i32& region )
OLD: void setVolumeData( const SbVec3s &dimension... )
NEW: void setVolumeData( const SbVec3i32 &dimension... )
Although existing programs should contine working unchanged, the older methods have been deprecated, and we recommend applications change to the new versions of these methods as they are more powerful and will have a longer lifespan.Note that in some cases the new method expects a reference instead of a pointer for some parameters. For example, SoVolumeDetail::getProfileValue().
The affected classes and their methods are:
SoVolumeDetail
- getProfileDataPos
- getProfileValue
- getFirstNonTransparentValue
SoLDMResourceManager
- setVolumeDim
SoVolumeData
- setVolumeData
- getVolumeData
- subSetting
- updateRegions
- loadRegions
- setSubSamplingLevel
- getSubSamplingLevel
- setPageSize
- getData
SoVRGenericFileReader
The box and subVolume fields of SoROI were changed as well. Previously they were of type SoSFBox3s. Now they are of type SoSFBox3i32.
- setDataChar
A new field was added to SoOrthoSlice and to SoObliqueSliceto allow for support of additive blending. The new field, composition, is analogous to the one in the SoVolumeRender class. Possible value are:
The default value is ALPHA_BLENDING for compatibility with current behavior. See the Reference Manual for details.
- ALPHA_BLENDING (default)
- SUM_INTENSITY (additive blending)
- MAX_INTENSITY
- MIN_INTENSITY
NOTE: Older versions of Open Inventor will not be able to read Inventor files that specify a value for this new field.
This was enhancement request 1023.
Several enhancements have been made to the SEGY file reader (SoVRSegyReader).
- SEGY IBM floating point format support has been added. Previously, only IEEE floating point format was supported.
- There are now new methods to get information from the header of the file:
bool getSegyFileHeader( SoVRSegyFileHeader& fileHeader ); bool getSegyTraceHeader( int traceNumber, SoVRSegyTraceIdHeader& traceHeader ); int getSegyTraceData( int traceNumber, void* &traceData, int start = 0, int size = -1 );An option was added to the SEGY reader to convert the input data type, for example convert 32-bit float data to 8-bit unsigned int data (to reduce memory usage).
Here is the method used to specify the desired data type:virtual SbBool setOutputDataType( SbBool doChange, SoVolumeData::DataType type );This feature can also be used when running the LDM converter, to reduce disk space and memory usage (there's a new command-line option for this).
This was enhancement request 1051.- Dump flag in SEGY reader. A new configuration parameter, IVVR_SEGY_DUMP, can be used to request that the file and trace headers be written to a file while processing the SEGY data file. This information may be helpful if the SEGY reader fails to read the file correctly.
The LDM Reader has been enhanced to allow you to add custom XML tags to your LDM file header, and then subsequently use the LDM Reader to retrieve them. This can be useful, for example, to store survey geo-position data in the file header.
The following method
void setXmlCallback( void (*xmlCB)( FILE*, void * userData ), void * userData );specifies the callback that SoLDMConverter will call when the LDM file header is generated. This allows the application to add custom XML tags. The custom tags (or any of the standard tags) can be read back in an application by using the following method:SoVRLdmFileReader::getXmlTag()A new example program, CustomTags, illustrates this new feature.This was enhancement request 1053.
VolumePro data loading is now integrated with LDM, resulting in much faster loading in several interesting cases (details below). Note that, unlike texture rendering, LDM does not support "mixed resolution" rendering on the VolumePro (this is not a native feature of the board).
- Data is loaded onto the VolumePro board using the LDM data manager (when LDM mode is active and the data file is in LDM format.) Previously data was always fetched directly from the VolumeViz reader, meaning that full resolution data was read from disk. Disk I/O is far slower than I/O to the VolumePro and is almost always the limiting factor in loading performance. Fetching data from the LDM manager allows much faster loading in several interesting cases, including:
Note that the maxResolutionThreshold parameter (see LDM tab in VolRend) is respected. So you can also force any resolution level to be loaded even if the full resolution volume would fit on the VolumePro (but would be slower to load).
- When switching from texture rendering to VolumePro rendering
In this case, some or all of the data tiles needed to load the VolumePro are already in system memory and do not need to be read from the disk.
- When full volume will not fit in VolumePro memory
In this case, we load a subsampled version of the volume directly from the LDM data file. This requires significantly less disk I/O than reading the full resolution volume. So loading data onto a 512 MB board can actually be faster than loading onto a 1 GB board (see IVVP_MEMORY_LIMIT for testing).
- A new configuration parameter limits VolumePro memory. This is useful for testing because it allows you to simulate running on a board with less memory. Maximum memory allowed is specified in kilobytes. For example to approximately simulate a 500 MByte board:
IVVP_MEMORY_LIMIT 500000
- Extend Mode
The default is now kExtendWithEdge (see VLIVolume::SetExtendMode) which generally produces a better image. This setting can be overridden using the environment variable IVVP_EXTEND_MODE, where 0 means kExtendWithBorder and 1 means kExtendWithEdge (default).
- Space Leaping
The VolumePro space leaping feature (off by default) can be be enabled using the environment variable IVVP_SPACE_LEAPING, where 0 means kSpaceLeapingOn and 1 means kSpaceLeapingNone. For info about this feature see VLIVolume::SetSpaceLeapingParameters.
- VLI 3.3
VolumeViz is now built with VLI 3.3 (the current version). You will need the VLI 3.3 DLL (on Windows) or the VLI 3.3 ".so" (on UNIX). You may need to install the device driver released with VLI 3.3. These files are included in the VolumeViz SDK.
VolumeViz 5.0 has a number of new features, the most significant of which is support for interactive navigation of very large data sets using the new LDM (Large Data Management) classes.
A key new feature of VolumeViz 5.0 is LDM (Large Data Management) mode. It allows the user to view and interactively naviagate throught vast amounts of data on systems ranging from laptops to fully immersive virtual environments.
Overview
For many volume rendering technologies, a large volume is one gigabyte. But today many volume data sets, for example seismic data, commonly exceed tens or even hundreds of gigabytes. These data sets easily exceed the available system memory, especially on 32-bit machines, and always exceed the available texture memory (still less than one gigabyte even on high-end boards). The VolumeViz 5.0 solution is a hierarchical, multi-resolution data manager called LDM. This innovative technology allows rendering of extremely large data sets with reliable interactive navigation even on relatively low-end machines. For best results the data is preprocessed to create a hierarchy of lower-resolution (subsampled) tiles. The VolumeViz 5.0 converter tool allows you to convert your data set to the LDM data format.
The tiles at each higher level represent a larger portion of the total volume at a lower resolution. So overall the top level tile contains a low resolution overview of the entire volume and the lowest level tiles contain the full resolution data. This preprocessing requires only roughly 15%-25% additional storage for the volume data (depending on whether the tiles are overlapped to avoid rendering artifacts at tile boundaries).
Generally the top level tile is loaded first, providing almost immediate visualization of the volume (or any portion of the volume). Then the image is automatically refined by loading higher resolution data and higher resolution textures. Interactivity is maintained because rendering always uses textures already loaded into texture memory. Although lower resolution data may be displayed temporarily, maximum image quality (with the available system resources) is reached quickly. The allocation of system resources depends on the current view, current objects (slices, subvolumes, etc.), and a set of user-controlled heuristics such as slices have higher priority than subvolumes.
In order to maintain interactivity, VolumeViz takes into account a variety of constraints including system memory, texture memory, rendering speed, data loading speed (disk-to-system memory), and texture loading speed. Data is loaded asynchronously using a separate thread, taking advantage of multi-processor systems. Performance and image quality automatically increase as system constraints are lifted, for example, more system memory, a faster disk drive, or an additional CPU.
In summary, LDM allows unprecedented access to extremely large data sets and at the same time provides a remarkably interactive user experience. The user perceives that any portion of the volume can be displayed immediately, the volume can be navigated smoothly at all times, slices and probes are responsive at all times, and image quality is automatically managed to the best possible level.Licensing
The LDM feature requires a separate LDM license string in addition to the usual VolumeViz license string. Contact your regional sales manager for pricing info and/or to request a temporary license if necessary.
Default
Because the LDM functionality offers significant benefits to users needing to display large volumes of data, i.e., most VolumeViz users, LDM mode is now the default mode. You can turn off LDM mode using the configuration keyword IVVR_40_COMPAT. Alternatively, you can turn it off programmatically using SoVolumeData::setPaging(TRUE).
See SoVolumeData.
A new file reader class, SoVRDicomFileReader, was added to provide support for reading DICOM 3.0 files.
See http://medical.nema.org/ for information on the file format.
This new feature is particularly useful, for example, when two slices intersect (line of intersection is more visible). Previously lights in the Open Inventor scene graph did not affect the rendering of SoOrthoSlice, SoObliqueSlice, or SoVolumeSkin.
Note that lights in the scene graph affect volume skin rendering, but not direct volume rendering. (SoVolumeRender has its own light.)
Previously, the SEGY reader supported 32-bit integer SEGY files with a single convention for determining the number of samples per trace. It has been enhanced to support all sizes of integers as well as float data, and can correctly determine the number of samples in most cases.
The config file keyword IVVR_DEBUG was previously only useful with a Windows debug build. It is now active in both release and debug builds on all platforms.
Note that the output is purposefully limited in a release build. However it will report useful information including:
- If 3D textures, paletted textures, etc. are supported
- If a VolumePro board is installed and usable.
MIN_INTENSITY, a new enum value for the composition field of SoVolumeRender, draws the minimum intensity for each pixel drawn along the viewing axis.
It is useful for displaying data volumes in which the background is of high intensity and the details of interest are of low intensity.Previously, only the following three enum values were supported:
MAX_INTENSITY, SUM_INTENSITY, and ALPHA_BLENDING.
SoOrthoSlice, SoObliqueSlice, and SoVolumeSkin have a new field (useRGBA) which allows you to force the use of RGBA textures, even if indexed textures were requested on the SoVolumeData node. RGBA textures allow using a larger colormap when the data values are larger than 8 bits. This field allows you to use indexed textures for SoVolumeRender (to reduce the amount of texture memory needed) but use RGBA textures for the nodes where the difference in texture memory needed is not significant.
The VolRend example program has been updated to incorporate the LDM features. It has also been enhanced with support for SpaceBall/SpaceMouse input. See the readme.txt file in the VolRend directory for instructions on using the SpaceBall/SpaceMouse.
The following are other new examples:
Example: $OIVHOME/src/VolumeViz/examples/GetLDMData/*
One of the most significant advances in VolumeViz 4.0 is that it now allows multiple volumes to be rendered correctly in the same scene. See the new SoVolumeGroup node and new example program "multivolumes". All SoVolumeRender nodes that are under the same SoVolumeGroup node will be rendered together with correct blending (subject to some limitations). The SoVolumeRender nodes could represent different volume data sets (see SoVolumeData) or different subvolumes (see SoROI) of the same volume data set.
For best results, use 3D texture rendering (SoVolumeData::TEX3D) and the viewAlignedSlices option. With these settings even volumes that are rotated with respect to each other are correctly rendered. Using 2D texture rendering (TEX2D), all the volumes must be aligned (i.e., their XYZ axes must be parallel) to get the correct image. There is a small performance decrease when multi-volume support is enabled. NOTE: Multi-volume rendering does not (in general) produce the correct image using a VolumePro board (we are still looking for a solution for this case).
SoVolumeSkin is a new geometry node that can be used in place of an SoVolumeRender node, but only draws the outer surfaces of the volume. When using an opaque color map this generates the correct image but can be many times faster than actual volume rendering. This should be particularly valuable for moving a subvolume in a seismic data set. SoVolumeSkin responds to SoROI and SoTransferFunction in exactly the same way as the SoVolumeRender node.
A new set of "volume geometry" nodes allow geometry to be drawn inside the volume and be automatically textured using the current volume data and color map. This geometry can be used, for example, to map volume data onto a ribbon of connected "slices", a fault surface or a well bore. The volume geometry nodes each have the same fields (plus two additional ones) as the corresponding standard geometry node, so defining volume geometry is essentially the same as defining standard geometry. The new nodes are:
You can use modeling transforms (for example an SoTransform node or a manipulator) to move, scale, and rotate volume geometry nodes. However note that if you also use transforms to move, scale, or rotate the entire volume, the transform node must occur before the SoVolumeData node in the scene graph. Applying a transform only to the SoVolumeRender node will result in an incorrect image for the volume geometry nodes.
- SoVolumeFaceSet
- SoVolumeIndexedFaceSet
- SoVolumeIndexedTriangleStripSet
- SoVolumeTriangleStripSet
These nodes now have an alternateRep field, similar to the DataViz nodes. The new setWriteAlternateRep method in SoVolumeRendering tells VolumeViz to automatically generate an alternateRep scene graph for slices using only standard texture and faceset nodes. This alternateRep allows the VolumeViz slices to be read and displayed correctly in any Open Inventor-based program, for example SceneViewer or 3SpaceAssistant, even if that program does not use the VolumeViz extension.
NOTE: Inventor files that contain this new field will not be readable by older versions of Open Inventor. See the Compatibility topic for more details.
SoROIManip is a new manipulator class derived from SoROI that provides a convenient 3D user interface for directly moving and resizing the subvolume and ROI boxes. The user interface is provided by an SoTabBoxDragger. The manipulator (optionally) constrains the dragger to the extent of the volume and directly updates the SoROI fields. See the new "roiManip" example program.
The new getSubVolume method is an alternative to getSubSlice that allows the application to return an entire brick of volume data instead of a single slice. It also allows the application to return a pointer to the data instead of (as currently) copying the data into memory allocated by VolumeViz. This should allow large volumes to be loaded much more quickly.
In addition, the getSubVolume method (with the new getSubVolumeInfo method described below) allows the application to return data that is already subsampled. Previously the application was required to always return raw (full resolution) data, which VolumeViz would subsample if necessary. VolumeViz will still do subsampling if necessary, but if the application returns data at the requested (or lower) subsampling level VolumeViz does not have to do that work.
Note that the application can return data that is lower resolution than requested by VolumeViz. This allows, for example, using an low resolution (already subsampled) "overview" volume the first time a brick is requested. Lower resolution bricks can be loaded into texture memory more quickly, so the user can get an initial image of a large volume much more quickly. The new loadRegions method in SoVolumeData can subsequently be used to force VolumeViz to reload the brick, allowing the application to replace it with higher resolution data.
VolumeViz always calls the new getSubVolumeInfo method before each call to getSubVolume. getSubVolumeInfo is passed the extent of the brick and the requested subsampling level. The application should return the actual subsampling level of the data that will be returned when getSubVolume is called for that brick. And also return a flag indicating if the data will be copied into VolumeViz memory or VolumeViz should use the data from application memory.
VolumeViz can now be used in multi-pipe programs, i.e., where there are multiple rendering threads traversing the scene graph at the same time and textures (possibly) cannot be shared between pipes.
VolumeViz shape nodes (e.g., SoVolumeRender, SoOrthoSlice, ...) can now be delayed and/or sorted according to the current transparency type (see SoGLRenderAction::TransparencyType). Delayed rendering can be useful to ensure that non-opaque VolumeViz objects are correctly blended with opaque geometry in the scene. Delayed rendering is disabled by default (for backward compatibility). It can be enabled using SoVolumeRendering::setDelayedRendering or by setting the environment variable IVVR_DELAY_RENDER.
Note that VolumeViz shapes are either delayed (any DELAYED_* type), delayed and sorted (any SORTED_* type), or drawn immediately (all other transparency types). VolumeViz shapes are always blended according to their own attributes, e.g., SoVolumeRender::composition. VolumeViz shapes are considered "transparent" if either the material transparency is non-zero or the transfer function (color map) contains at least one entry with an alpha value less than one. Otherwise VolumeViz shapes are considered opaque and are not delayed or sorted.
The following basic example programs have been added and can be found in the .../src/VolumeViz/examples directory:
The VolRend demo/example program has been revised to use the new DialogViz user interface tools. Instead of multiple dialog boxes, the user interface is contained in a convenient tabbed dialog box. There are new controls in the dialog including:
- simpleVolume
- colorMap
- roiManip
- multiVolumes
VolRend also uses the new SoRoiManip instead of "ad hoc" draggers.
- A slider to control the background color
- A combobox to select real volume rendering or volume
- A button to generate a .iv file with alternateRep geometry for the slices.
Support for the VolumePro 1000 board (www.terarecon.com) has enhanced by rebuilding with the latest release of VLI (v3.1). This release allows the VolumePro 1000 to generate correct images when a perspective camera is being used.
NOTE: If you are using a VolumePro 1000 board, be sure to install the VLI 3.1 compatible driver included with the VolumeViz SDK.
The Volume Rendering extension has been renamed to VolumeViz.
VolumeViz 3.0 is compatible with (requires) Open Inventor 3.1
No major enhancements were added in this version which is compatible with Open Inventor 3.0.
A new rendering method draws slices through the volume using only one 2D
texture. The other 2D texture map rendering method requires that the entire
volume fit in OpenGL texture memory, which is much more limited than system
memory. Using this new method, the volume size is only limited by system
memory, because only one slice at a time is loaded into texture memory.
Rendering speed is affected because the texture data for each slice must
be loaded before the slice is drawn, but for large volumes this may be the
only choice. To enable this method use the new storageHint TEX2D_SINGLE.
Bonus: Rendering a very large volume is usually not interactive, even
with powerful 3D hardware. By default, rendering is "double buffered",
meaning the image is not displayed until it is completely rendered. But
for a large volume it may be better to allow the user to watch the volume
being rendered. The new SoFrontBufferGroup node in Open Inventor
2.6.2 allows one part of the scene graph to be double buffered and another
part to be drawn "while you watch". This is good for TEX2D_SINGLE
rendering because partial rendering may be useful and it allows the user
to interrupt a rendering that is not useful (see SoVolumeRender::setAbortCallback).
The VolRend example program has been enhanced to demonstrate this
technique.
Previously, in order to use 3D texture rendering, the entire volume had
to fit in OpenGL texture memory as a single 3D texture image. This is very
inefficient when the volume does not have "power-of-2"
dimensions (as required for an OpenGL texture image) because the next larger
power-of-2 image size must be used. In version 2.0, the volume is automatically
subdivided into power-of-2 "bricks" (subvolumes) which use texture
memory more efficiently. In some cases this allows larger volumes to be
loaded in the same amount of
texture memory. In some cases rendering speed is affected because the texture
data for each brick must be loaded before the slices are drawn for that
brick. However the better image quality obtained with 3D texture rendering
(compared to 2D textures) may be worth it.
Limitation: Bricking is not activated (for now) when lighting is on.
Deactivated by setting SoVolumeRender::bricking to FALSE.
A better quality image is produced by drawing slices through the volume
that are always perpendicular to the current direction of view. In particular
this avoids the changes in brightness or quality sometimes seen with the
previous algorithm when switching from one slice axis to another. Some additional
CPU time is required to compute the geometry for each view aligned slice,
but usually this is much smaller than the rendering time anyway.
NOTE: Only for 3D texturing. And (for now) only when no bricking. Activated
by setting SoVolumeRender::viewAlignedSlices to TRUE.
New "pick detail" classes SoOrthoSliceDetail, SoObliqueSliceDetail
and SoVolumeRenderDetail were added. A successful pick operation
returns an SoPickedPoint object. When the picked geometry is a slice
or volume, use the getDetail method and cast the result to the appropriate
class to get extra information about the location
of the pick. SoOrthoSliceDetail and SoObliqueSliceDetail return
information about the picked voxel on the slice, including:
SoVolumeRenderDetail returns information about the first (closest) non-transparent voxel along the pick ray and/or information about all the voxels intersected by the pick ray (called a profile):
The VolRend demo/example program has been enhanced to display the
result of picking in a separate popup window. Remember you must put the
viewer in selection mode by clicking the "arrow" button to do
picking. If you see the "hand" cursor you are in viewing mode.
Not implemented yet - will be in production release.
When the OpenGL TexSubImage3D function is available (generally it is if 3D textures are supported on your machine), textures that do not have "power of 2" dimensions are now loaded directly instead of allocating memory for a "power of 2" temporary image.
There is only a small change in the the version number, but there are some major enhancements, including dramatic improvements in performance and image quality for both texture map and VolumePro(tm) rendering.
NOTE 2: Dynamic color lookup is disabled if lighting is enabled.