Package com.openinventor.volumeviz

VolumeViz is an Open Inventor extension.

Introduction

With the ongoing increases in desktop computing power, volume rendering is now more accessible than ever before. Volume rendering is used in a large variety of applications such as medical imaging, meteorology, molecular modeling, nondestructive testing, failure analysis, fluid dynamics, electronics, oil exploration, magnetism, and more.

The VolumeViz module allows you to visualize 3D sampled data efficiently by providing the key features of volume rendering. The main concepts such as classification, compositing, interpolating, lighting, slicing, and clipping are supported in this module as a set of nodes that are fully integrated with Open Inventor. The application programming interface is intentionally compact in order to make the programmer's task as easy as possible.

As proof of its simplicity, rendering a 3D data set minimally requires instantiation of only two classes: one for describing the data and one for drawing the volume. In this case, the volume would be rendered using the default gray color map.

Because the VolumeViz module is integrated with Open Inventor, you can mix volume rendering and conventional 3D geometry (subject to possible limitations of the hardware) to make a more meaningful image.

This module has been designed to take advantage of 3D graphics or specialized volume rendering hardware, while at the same time providing the highest possible image quality.

Program/Scene Graph Structure

We assume you are already somewhat familiar with Open Inventor programming. Using the Volume Rendering nodes is basically the same as using any Open Inventor nodes. Just as the SoCoordinate node must be traversed before the SoIndexedFaceSet node, the SoVolumeData node must be traversed before the SoVolumeRender node, and so on. A simple program/scene graph structure might look something like the following code. An ellipsis ("...") indicates other (typical Open Inventor application) code omitted for clarity.

Note: In this simple example, the entire volume is read into a contigous block of system memory. This is only appropriate for small volumes. See SoVolumeData for other methods of loading data in VolumeViz. 

 ...
 import com.openinventor.ldm.nodes.SoTransferFunction;
 import com.openinventor.volumeviz.nodes.SoVolumeData;
 import com.openinventor.volumeviz.nodes.SoVolumeRender;
 import com.openinventor.volumeviz.nodes.SoVolumeRendering;
 ...
 // Scene root
 SoSeparator pRoot = new SoSeparator();
 
 // Read the data (application supplied function)
 int Xdim, Ydim, Zdim;
 ByteBuffer pData = loadMyVolumeData(Xdim, Ydim, Zdim);
 
 // Add VolumeData to scene graph
 SoVolumeData pVolData = new SoVolumeData();
 pVolData.data.setValue(new SbVec3i32(Xdim, Ydim, Zdim), new SbDataType(DataTypes.UNSIGNED_BYTE), pData);
 pVolData.extent.setValue(-Xdim / 2.f, -Ydim / 2.f, -Zdim / 2.f, Xdim, Ydim, Zdim);
 
 pRoot.addChild(pVolData);
 
 // Add TransferFunction (color map) to scene graph
 SoTransferFunction pTransFunc = new SoTransferFunction();
 pRoot.addChild(pTransFunc);
 
 // Add VolumeRender to scene graph
 SoVolumeRender pVolRend = new SoVolumeRender();
 pRoot.addChild(pVolRend);
 ...

Rendering Notes

Following are some notes on specific characteristics of the various rendering techniques. This is not intended to be a comprehensive evaluation of the tradeoffs between rendering techniques. Which technique is really the "best" depends heavily on the hardware you have, the size and type of data, and on the specific requirements of your application.

Note that lights in the Open Inventor scene graph do not affect rendering of SoVolumeRender. Only the single light specified on the SoVolumeRender node (optionally) affects this node.

Generally, volumes and slices should be placed after other (opaque) geometry in the scene graph so they will be drawn last and produce the correct image for transparency. However, the method SoVolumeRendering.setDelayedRendering can be used to request that partially transparent volumes and slices be automatically delayed, similar to other transparent geometry. It is not necessary to explicitly enable blended transparency when rendering volumes and slices.

2D Textures (TEX2D)

  • Hardware to accelerate rendering of 2D texture mapped geometry is widely available. The current implementation uses OpenGL texture objects, so OpenGL 1.1 or higher is required.
  • More texture memory is required in total than for TEX3D because three sets of textures are required (one set each for the X, Y, and Z axes).
  • Modifying the light forces all the texture images to be regenerated. This is generally not an interactive operation.
  • Modifying the transfer function may force texture images to be reloaded unless the graphics board supports the OpenGL paletted texture extension.

    3D Textures (TEX3D)

  • The current implementation can use either OpenGL 1.2 or OpenGL 1.1 with the Texture3D extension.
  • Generally rendering speed is slightly slower than using 2D textures, but image quality is slightly better.
  • Some graphics boards render 3D textures but without hardware acceleration. VolumeViz attempts to detect this case, but cannot in all cases.
  • Modifying the light forces all the texture images to be regenerated. This is generally not an interactive operation.