1.1.2. VolumeViz Features

This section is a quick tour of all the features in VolumeViz. It can also be used as a “quick reference” that links the various features to the related nodes, fields and methods.

Volume Data

Use the SoVolumeData⁽^C++^|^Java^|^.NET⁾ node to access volume data. The data volume can be given by:

A file name (VolumeViz supports DICOM, SEGY, LDM and other formats directly)
A volume reader (application provided plugin to handle a specific file format)
A block of memory
Conversion to LDM format

See Section 1.2, “Data” for more information.

Volume Properties

Size: number of voxels on each axis
Extent: geometric extent of the volume in 3D space
Voxel size/spacing: may be uniform, different for each axis or even vary along each axis
Data type: integer or floating point scalar values, RGBA values, boolean values (mask)
Number of significant bits: for example 12 bit values in 16 bit words
Data range: actual range of values to map into the color table
Many other volume properties can be specified using fields of SoDataSet⁽^C++^|^Java^|^.NET⁾ and SoVolumeData⁽^C++^|^Java^|^.NET⁾, for example, the amount of CPU memory and GPU memory that each volume can use. Application specific properties of a volume, for example seismic survey properties, can be stored in the LDM header file as custom XML tags.

See Section 1.2, “Data” for more information.

Volume Visualization

The volume data is specified by an SoVolumeData⁽^C++^|^Java^|^.NET⁾ node. Multiple volumes can also be specified.
The region of voxels to be rendered (the "region of interest") can be specified using an SoROI⁽^C++^|^Java^|^.NET⁾ node.
The range of data values to be mapped into the transfer function can be specified using an SoDataRange⁽^C++^|^Java^|^.NET⁾ node.
The color and opacity associated with each data value can be specified using an SoTransferFunction⁽^C++^|^Java^|^.NET⁾ node.
The base material properties of voxels, e.g. emissive and specular color, can be specified using an SoMaterial⁽^C++^|^Java^|^.NET⁾ node.
VolumeViz provides many different ways of visualizing volume data, including:
- SoOrthoSlice⁽^C++^|^Java^|^.NET⁾: Renders a single axis aligned slice.
- SoObliqueSlice⁽^C++^|^Java^|^.NET⁾: Renders a single arbitrarily aligned slice.
- SoFenceSlice⁽^C++^|^Java^|^.NET⁾: Renders a "strip" of connected oblique slices.
- SoVolumeSkin⁽^C++^|^Java^|^.NET⁾: Renders the faces of the current Region of Interest (see SoROI).
- SoVolumeIndexedFaceSet⁽^C++^|^Java^|^.NET⁾ (etc): Renders a "slice" made up of arbitrary geometry.
- SoVolumeIsosurface⁽^C++^|^Java^|^.NET⁾: Renders the isosurface defined by the specified data value.
- SoVolumeRender⁽^C++^|^Java^|^.NET⁾: Renders the volume using direct volume rendering.
  Figure 1.7. SoOrthoSlice, SoObliqueSlice, SoFenceSlice
Volume rendering quality settings include number of samples, pre-integration and gradient quality.
Volume rendering effects include edge coloring, boundary opacity and 2D edge enhancement.
Volume rendering modes include MIP, isosurface and voxelized rendering.
Shadows can be enabled for lighted volume primitives using an SoShadowGroup⁽^C++^|^Java^|^.NET⁾ node.
Many parameters related to memory management and performance optimizations can be specified using SoLDMGlobalResourceParameters⁽^C++^|^Java^|^.NET⁾ and SoLDMResourceParameters⁽^C++^|^Java^|^.NET⁾.

See Section 1.3, “Appearance”, Section 1.4, “Slice Rendering”, Section 1.5, “Volume Rendering” for more information.

Advanced volume visualization

Custom shaders
Custom transfer functions, custom rendering effects and custom blending are just a few of the many possibilities that can be implemented using an SoVolumeShader⁽^C++^|^Java^|^.NET⁾ node and GLSL shader functions. (GLSL is the standard OpenGL shader language.) Shader functions can be loaded from disk or precompiled in the application. VolumeViz provides a framework of prebuilt shader functions for commonly used calculations and effects. This allows applications to extend or replace stages in the rendering pipeline while still taking advantage of other VolumeViz features. VolumeViz also provides an advanced “virtual texture” mechanism on the GPU that allows shader programs to access any data in the volume without worrying about tile boundaries.
See Section 1.8, “Shaders” for more information.
Figure 1.8. Custom shader for co-blending multiple volumes
Clipping
Volume visualizations can be clipped in multiple ways:
- By clipping planes using an SoClipPlane⁽^C++^|^Java^|^.NET⁾ node, like any Open Inventor geometry.
- By a box in voxel coordinates using an SoROI node. An optional exclusion box allows cut-away views like the “chair cut” in seismic visualization.
- By any closed shape defined by polygonal geometry using an SoVolumeClippingGroup⁽^C++^|^Java^|^.NET⁾ node.
- By a "height field" surface (for example a seismic horizon) using an SoUniformGridClipping⁽^C++^|^Java^|^.NET⁾ node.
- By an arbitrary voxel region using an SoVolumeMask⁽^C++^|^Java^|^.NET⁾ node.
- Multiple clipping techniques may be combined to “sculpt” volume regions.
See Section 1.7, “Clipping” for more information.
Figure 1.9. Volume clipped around a well bore
Interactivity
VolumeViz allows the creation of highly interactive volume rendering applications:
- Picking works for VolumeViz objects like for any Open Inventor geometry. Including the application can get detailed information, like the voxel value, from a pick (see for example SoOrthoSliceDetail⁽^C++^|^Java^|^.NET⁾).
- VolumeViz provides specialized draggers and manipulators to allow users to directly interact with volume rendering scenes. For example SoOrthoSliceDragger⁽^C++^|^Java^|^.NET⁾ allows dragging a slice through the volume.
- Modifying VolumeViz property nodes (like any Open Inventor node) automatically causes the scene graph to be re-rendered. For example changing the color map by modifying the fields of SoTransferFunction⁽^C++^|^Java^|^.NET⁾.
- The volume itself can be modified interactively using the “volume edit” methods (startEditing, finishEditing, etc) in SoVolumeData⁽^C++^|^Java^|^.NET⁾. Volume editing supports undo and redo.
- For very large volumes VolumeViz provides multiple options for temporarily reducing the rendering complexity while interacting with the scene. See for example the SoInteractiveComplexity⁽^C++^|^Java^|^.NET⁾ node.
Transforming data
Volume data can transformed "on the fly" at several stages in the pipeline:
- The SoLDMDataTransform⁽^C++^|^Java^|^.NET⁾ class (see the dataTransform field of SoDataSet⁽^C++^|^Java^|^.NET⁾) applies a computation to each LDM data tile requested from the volume reader before the tile is stored in system memory. This can be used to apply “static” filters to the data, for example to scale and offset data values.
- The SoVolumeTransform⁽^C++^|^Java^|^.NET⁾ node applies a computation to the LDM data tiles just before they are sent to the GPU. This can also be used to apply dynamic filters to the data, for example computing seismic attribute values.
- Both transform mechanisms can be used to create multiple data sets from a single data set.
- Custom shaders (SoVolumeShader⁽^C++^|^Java^|^.NET⁾) can also be used to do computation during rendering.
See Section 1.9, “Transforming and Combining Volumes” for more information.
Multiple data sets
- Multiple SoVolumeData⁽^C++^|^Java^|^.NET⁾ nodes can be inserted in the same scene graph.
- If the volumes are independent and rendered separately, use an SoVolumeGroup⁽^C++^|^Java^|^.NET⁾ node to manage and correctly render intersecting regions.
- Multiple volumes can be combined into a single data set or single rendering using data compositing or render compositing. Use an SoMultiDataSeparator⁽^C++^|^Java^|^.NET⁾ as the parent of the nodes that will be composited.
- Data compositing combines multiple volumes (see SoDataCompositor⁽^C++^|^Java^|^.NET⁾) on the CPU at data loading time. Data compositing can be used, for example, to visualize the difference between two data sets.
- Render compositing combines multiple volumes on the GPU at render time using a fragment shader (see SoVolumeShader⁽^C++^|^Java^|^.NET⁾). Render compositing can be used, for example, to implement “co-blending” of multiple volumes or to implement multi-channel color combining.
See Section 1.9, “Transforming and Combining Volumes” for more information.
Data Access
LDM is a powerful data manager for large volume data and VolumeViz provides a Data Access API that allows applications to take advantage of this for applying algorithms to their volume data.
- SoLDMTopoOctree⁽^C++^|^Java^|^.NET⁾ allows the application to query the structure of the tile hierarchy.
- SoLDMDataAccess⁽^C++^|^Java^|^.NET⁾ provides the methods to extract data from a volume. The data is accessible whether the SoVolumeData⁽^C++^|^Java^|^.NET⁾ is part of a scene graph or not.
- Data access methods can be invoked synchronously or asynchronously to allow simultaneous loading and computation.
- The application can request data at any resolution level, independent of the resolution level currently being used for rendering
- VolumeViz supports a variety of data requests including:
  - Subvolume: The set of voxels inside a specified subvolume.
  - Plane: The set of voxels intersecting an arbitrary plane.
  - Line: The set of voxels intersecting an arbitrary line.
  - Trace: A column of axis aligned voxels (e.g. a seismic trace).
  - Polyline: The set of voxels intersecting an arbitrary polyline.
  - Tile: Direct access to the tile containing a specified voxel.
- Extracted, modified or synthesized data can be written to an LDM format file by subvolume or tile using the SoLDMWriter⁽^C++^|^Java^|^.NET⁾ class.
See Section 1.10, “Data Access and Computing” for more information.
Computation
Volume computations can take advantage of the Open Inventor computing framework to manage data, devices and algorithms on the CPU and GPU (using CUDA or OpenCL).
- The SoDevice class abstracts computing and rendering devices. Device specific classes, for example SoCpuDevice⁽^C++^|^Java^|^.NET⁾, allow querying the number of available devices, available memory, etc.
- The SoBufferObject⁽^C++^|^Java^|^.NET⁾ class abstracts data management. Device specific data objects, for example SoCpuBufferObject⁽^C++^|^Java^|^.NET⁾ allows the application to control where memory is actually allocated. It also allows algorithms to be implemented on CPU or GPU (or both) using SoBufferObject⁽^C++^|^Java^|^.NET⁾ without knowing where the memory is allocated (Open Inventor will transfer when necessary).
- The algorithm classes provide optimized versions of some useful computations for each class of computing device (CPU, GPU). See SoArithmetic⁽^C++^|^Java^|^.NET⁾, SoConvolution⁽^C++^|^Java^|^.NET⁾, SoSeismic⁽^C++^|^Java^|^.NET⁾, etc.
- The computing framework classes are integrated with the data transform, compositing and data access classes mentioned previously.
See Section 1.9, “Transforming and Combining Volumes” for more information.

Prev	Up	Next
1.1.1. What is VolumeViz	Home	1.1.3. VolumeViz Basics