This node defines an oblique (arbitrarily oriented) slice which is the intersection of the volume data defined by an OIV.VolumeViz.Nodes.SoVolumeData node and the plane defined by the OIV.VolumeViz.Nodes.SoObliqueSlice.plane field.

The OIV.VolumeViz.Nodes.SoVolumeData node can be specified with OIV.VolumeViz.Nodes.SoObliqueSlice.dataSetId. When this field is set to 0, the last OIV.VolumeViz.Nodes.SoVolumeData node on state is used.

For a non-RGBA (scalar valued) volume, each voxel's RGBA value is determined by the current OIV.LDM.Nodes.SoDataRange and OIV.LDM.Nodes.SoTransferFunction. The current diffuse color and transparency (set, for example, with an OIV.Inventor.Nodes.SoMaterial node) modify the appearance of the slice. This means that, for example, the current transparency can be used as a global alpha value to modulate the overall opacity of the slice. For an RGBA volume each voxel's RGBA value comes directly from the volume data.

The interpolation field controls how the texture is interpolated.

The alphaUse field (OIV.VolumeViz.Nodes.SoSlice) controls how the voxel's alpha component is used when drawing the slice.

Optionally a bump mapping effect may be applied. Normal vectors are automatically computed from the data value gradient. The enableBumpMapping and bumpScale fields (OIV.VolumeViz.Nodes.SoSlice) control whether bump mapping is active and the intensity of the effect.

Notes:

• Transformation matrices: The volume size and orientation (like geometry) can be modified by transformation nodes in the scene graph and this in turn modifies the appearance of volume visualization nodes. However the same transformation must be applied to the volume data node and all volume visualization nodes associated with that volume. So effectively any transformation nodes that affect the volume must be placed before the volume data node.

• Plane normal: The "polarity" of the plane normal (for example whether it is +Z or -Z) doesn't affect rendering the oblique slice. However it's very important if you also use that plane to define a clipping plane. The clipping plane will clip away everything on the side of the plane *opposite* the normal vector direction. So to clip away the "front" (+Z) of the volume set the normal to 0,0,-1.

• Picking: The entire slice is pickable, even where it is transparent as a result of the current transfer function. The OIV.VolumeViz.Details.SoObliqueSliceDetail class allows you to get the voxel position and value after picking.

• Dragging: It is possible to interactively translate and rotate slices using an Open Inventor dragger, e.g. OIV.Inventor.Draggers.SoTranslate1Dragger. However the dragger's field values must be converted to an OIV.Inventor.SbPlane. For a dragger that has a convenient "plane" field that can be directly connected, see the ClipPlaneDragger article in the Resources section of the Open Inventor Forum: http://forum.openinventor.com/showthread.php?t=733 (registration is required to view this section of the forum).

• Interpolation: Interpolation is specified using the interpolation field. The default (LINEAR) does bi-linear interpolation between voxel values. The NEAREST value can be used to display individual voxels. For best image quality we recommend using the TRILINEAR or MULTISAMPLE_12 value.

• Data range: By default VolumeViz maps the entire range of the voxel's data type (e.g. 0..65535 for unsigned short) into the colormap. This is often correct for byte (8 bit) voxels, but seldom correct for 16 bit voxels and never correct for floating point voxels. Use an OIV.LDM.Nodes.SoDataRange node to specify the actual (or desired) range of data values to be mapped. Also use an OIV.LDM.Nodes.SoDataRange node to implement brightness/contrast control like the Window/Level setting commonly used with medical images.

• Clipping: Volume primitives can be clipped using a region of interest (OIV.LDM.Nodes.SoROI), geometry (OIV.VolumeViz.Nodes.SoVolumeClippingGroup) and/or height fields (OIV.VolumeViz.Nodes.SoUniformGridClipping). They are also clipped by OpenGL clipping planes (OIV.Inventor.Nodes.SoClipPlane), but we recommend using the VolumeViz clipping nodes instead.

• Material: The color of each voxel is modulated by the current diffuse color in the traversal state. The default diffuse color is 0.8,0.8,0.8. This results in full intensity values in the color map being displayed as 80% intensity. Therefore we recommend adding an OIV.Inventor.Nodes.SoMaterial node before the slice and setting its diffuseColor field to full white (1,1,1).

• Transparency:

  • Typically the color map (OIV.LDM.Nodes.SoTransferFunction) used for volume rendering (OIV.VolumeViz.Nodes.SoVolumeRender) assigns transparency (alpha < 1) to some voxel values. If you want to use the same color map for slice rendering, but render the slice completely opaque, set the alphaUse field to ALPHA_OPAQUE. This overrides the alpha values in the color map (or an RGBA volume). However it does not affect transparency assigned using an OIV.Inventor.Nodes.SoMaterial node.

  • If you want to adjust the overall transparency of the slice, add an OIV.Inventor.Nodes.SoMaterial node and set its transparency field (keeping alphaUse set to ALPHA_AS_IS). Effectively a scale factor 1-transparency is applied to each voxel's alpha value.

  • Intersecting transparent slices cannot be rendered correctly by the basic blending transparency algorithms. To render this case correctly, set the transparency algorithm to SORTED_PIXEL using the viewer class or OIV.Inventor.Actions.SoGLRenderAction.

• Voxel edges: The edges of the voxels can also be rendered. See options in the OIV.VolumeViz.Nodes.SoVolumeRenderingQuality node.

• Custom shaders: The current OIV.VolumeViz.Nodes.SoVolumeShader node, if any, allows custom shaders to be defined for special computation or rendering effects, including blending multiple volumes.

• Composition with Multiple Data: It is possible to compose datasets that have different dimensions, tile sizes and transformations. In order to help fetch the correct data values in custom shaders, texture coordinates conversion functions are provided in the VolumeViz/vvizStructure.h shader include. For instance,

  Copy

  vec3 VVizTextureToTextureVec(in VVizDataSetId datasetSrc, in VVizDataSetId datasetDst, in vec3 texCoord);

  can be used to convert texture coordinates related to one dataset to texture coordinates related to another dataset. The conversion is based solely on the transformations applied to each dataset, which are defined by their model matrix and their extent. Please note that the model matrix of a dataset is defined by to the OIV.Inventor.Nodes.SoTransformation nodes that are placed before the OIV.LDM.Nodes.SoDataSet node in the order of the traversal.

• Performance:

  • Tile size: For backward compatibility, the default tile size is still only 64. This is quite small for modern CPU/GPU hardware. The smaller the tile size, the larger the total number of tiles that must be managed by VolumeViz. This overhead can be significant, especially for operations that require reloading the data textures on the GPU, for example, changing the data range (OIV.LDM.Nodes.SoDataRange). For smaller volumes, like 512^3, it can be efficient to set the tile size large enough to contain the entire volume. For very large volumes, larger tile sizes are efficient for OIV.VolumeViz.Nodes.SoVolumeRender but somewhat inefficient for slice rendering because complete tiles must be loaded even though the slice only uses part of the data. Applications should experiment. For volumes stored in LDM file format, the tile size must be specified when the volume is converted to LDM (see OIV.LDM.Converters.SoConverter and the "-t" option). For other data data formats the tile size can be specified using the OIV.VolumeViz.Nodes.SoVolumeData node's ldmResourceParameters field, but only after setting the filename field or calling the SetReader()method.

  • LDM_USE_IN_MEM_COMPRESSION VolumeViz always manages data as "tiles", regardless of the data format. In many cases VolumeViz must create (or uncompress) the tiles at run time. These cases include in-memory volumes, any volume reader that does not implement the readTile() method (this includes all built-in formats except LDM, e.g. DICOM, SEGY, ...) and compressed LDM format files. If this variable is true (the default), VolumeViz only keeps a small cache of created/uncompressed tiles in CPU memory. If a tile's data is needed and that tile is not in the cache, the tile must be recreated. This overhead can be significant, especially for operations that require recreating all the data textures on the GPU, for example changing the data range (OIV.LDM.Nodes.SoDataRange). We recommend setting this variable to false (see OIV.Inventor.SoPreferences) unless saving CPU memory is critical.

EXAMPLE

For simple data sets, a basic VolumeViz rendering could be achieved with only a few nodes: minimally an OIV.VolumeViz.Nodes.SoVolumeData node to identify the data set and one rendering node. However most data sets need at least some of the additional nodes shown here in order to get a correct and useful rendering. Most applications will need additional nodes to take advantage of region of interest, interaction, clipping and other VolumeViz features. Please consider the code shown here as simply a guideline and a starting point for exploring the many powerful features available in Open Inventor.

Note that some of the property nodes (data, material, color map, etc) will typically be shared by multiple rendering nodes. In other words the volume usually only needs to be loaded once, using a single OIV.VolumeViz.Nodes.SoVolumeData node, then multiple slices and/or regions can be rendered using that data node.

Also note that this example is for a data volume, where each voxel can be considered a discrete sample from a continuous data field and interpolation should be used to compute values between voxel centers. If you are rendering a label volume, then each voxel is an "id" assigning that voxel to a specific material, object, etc. In this case, set the interpolation field to NEAREST to disable interpolation.

SoPreferences.SetValue( "LDM_USE_IN_MEM_COMPRESSION", "0" );

SoSeparator volSep = new SoSeparator();
root.AddChild( volSep );

SoVolumeData volData = new SoVolumeData();
volData.fileName.Value = "$OIVNETHOME/src/demos/data/VolumeViz/3DHead.vol";
volSep.AddChild( volData );

SoDataRange volRange = new SoDataRange();
if (volData.GetDatumSize() > 1)
{
   double minVal, maxVal;
   volData.GetMinMax( out minVal, out maxVal);
   volRange.min.Value = minVal;
   volRange.max.Value = maxVal;
}
volSep.AddChild( volRange );

SoTransferFunction volTF = new SoTransferFunction();
volTF.predefColorMap.Value = SoTransferFunction.PredefColorMaps.INTENSITY;
volSep.AddChild( volTF );

SoMaterial volMat = new SoMaterial();
volMat.diffuseColor.SetValue(1, 1, 1);
volSep.AddChild( volMat );

SoVolumeShader volShader = new SoVolumeShader();
volShader.interpolateOnMove.Value = true;
volSep.AddChild( volShader );

SoObliqueSlice slice = new SoObliqueSlice();
SbBox3f volext = volData.extent.Value;
SbVec3f center = volext.GetCenter();
slice.plane.Value = new SbPlane(new SbVec3f(0, 0, 1), center[2]);
slice.interpolation.Value = SoVolumeShape.Interpolations.MULTISAMPLE_12;
volSep.AddChild( slice );

FILE FORMAT/DEFAULT

ObliqueSlice {

dataSetId	0
plane	0, 0, 1, 0
interpolation	LINEAR
alphaUse	ALPHA_BINARY
useRGBA	false
alternateRep	NULL
enableBumpMapping	false
bumpScale	1.0

}

ACTION BEHAVIOR

OIV.Inventor.Actions.SoGLRenderAction Draws a textured polygon based on current OIV.VolumeViz.Nodes.SoVolumeData, OIV.LDM.Nodes.SoTransferFunction, and OIV.LDM.Nodes.SoROI nodes.

OIV.Inventor.Actions.SoGetBoundingBoxAction Computes the bounding box that encloses the slice.

Reference