|
Open Inventor Release 2025.2.2
|
|
| |
|
Open Inventor Release 2025.2.2
|
|
|
| |
Generally speaking, slices are a planar surface or a collection of planar surfaces, on which VolumeViz displays colors mapped from the values of the voxels that are intersected by the surface(s). Axis aligned slices (called ortho slices in VolumeViz) are the traditional first tool for exploring the data in a volume, but VolumeViz supports more complex slice types for specific purposes, including application defined slices (called volume geometry here) which can be curved surfaces, cylinders and so on. The slice primitives generally provide high performance and high image quality compared to volume rendering, but compared to volume rendering can only provide clues about the internal structure of the volume. All the slice type primitives, except volume geometry, are derived from the base class SoSlice.
The appearance of slice primitives is primarily determined by the SoMaterial, SoDataRange and SoTransferFunction (color map) nodes described in Appearance. The appearance of slices is also affected by slice specific properties including alphaUse, interpolation and bump mapping which are described in this section. In addition, custom shader functions may be applied to slices for special computation or rendering effects, for example co-blending multiple volumes, as described in Shaders and Transforming and Combining Volumes.
Lighting
Like other Open Inventor geometry, the appearance of slice primitives is automatically affected by light nodes in the scene graph, e.g. the viewer headlight and SoDirectionalLight nodes. Like other geometry, lighting can give important visual cues about the shape of objects and the relationships of objects in the scene. For slices, lighting is particularly useful for highlighting where two or more slices intersect (one of the slices will typically be brighter than the other because it is more perpendicular to the camera). Lighting is also useful for highlighting the bump mapping effect. However when interpreting the color of voxels on a slice the user must be aware that lighting modifies the intensity (and possibly the color) of the slice. By default, turning off all lights in the scene will cause slices to be rendered black. To prevent lighting from affecting a slice and render with its true colors, use an SoLightModel node with the model field set to BASE_COLOR.
VolumeViz supports the complete Open Inventor lighting model (which is the same as the OpenGL lighting model). So when lighting is enabled, you can control the ambientColor, specularColor, shininess and other properties of voxels using an SoMaterial node. Lighting is enabled by default for slice and height field primitives. Multiple lights are supported and the light color, intensity and direction (see SoLight and subclasses) affect rendering. For convenience, two-sided lighting is automatically enabled for slice primitives (but not for height field primitives).
Like other Open Inventor geometry, when lighting is enabled slice primitives can cast and receive shadows. Shadows may be useful in some applications to give visual cues about the relationships (particularly depth ordering) of objects in the scene. To enable shadows, put the slice primitives under an SoShadowGroup node and set its method field to VARIANCE_SHADOW_MAP.
Slices can be made partially transparent using SoMaterial or the transfer function. Correctly rendering scenes containing transparent geometry is complex and can reduce rendering performance. The transparency rendering mode is specified using the setTransparencyType() method in the Open Inventor viewer class (or the SoGLRenderAction). When using opaque slices, which is often the case, one of the basic transparency modes like DELAYED_BLEND should be sufficient to get the correct image. When using transparent slices it is usually necessary to use the most complex transparency mode DELAYED_SORTED_LAYERS_BLEND. In extreme cases it may be necessary to increase the number of rendering passes using the setSortedLayersNumPasses() method in SoGLRenderAction.
Clipping
The geometry of slices can be clipped by clip planes (SoClipPlane), region of interest (SoROI), polygonal shapes (SoVolumeClippingGroup), height field surfaces (SoUniformGridClipping) and mask volumes (SoVolumeMask) as described in Clipping.
Interaction
By default slices are pickable (even where transparent) and the respective slice detail classes, for example SoOrthoSliceDetail allow you to query the position and value of the picked voxel. Open Inventor draggers (see SoDragger) can be used to implement interactive dragging, rotation, etc of slices.
Whether the alpha (opacity) value comes from an RGBA value or the color map, the alphaUse field controls how a slice primitive uses that value. The default value is ALPHA_BINARY meaning that an alpha value of zero is fully transparent as usual, but all non-zero alpha values are considered completely opaque. The ALPHA_AS_IS value means to interpret alpha values in the usual way as a fraction of opacity. The ALPHA_OPAQUE value means to ignore alpha values and render the slice as completely opaque. This is useful because color maps for volume rendering typically have (at least some) low alpha values. The ALPHA_OPAQUE value allows the convenience of using the same color map for both volume rendering and for slices, but still having opaque slices.
Slices are rendered using OpenGL texture mapping and a 2D texture extracted from the data volume. The interpolation field (inherited from SoVolumeShape) controls how data values (or color values in the case of an RGBA volume) are interpolated for locations that do not fall precisely on a voxel center. NEAREST uses OpenGL “nearest neighbor” interpolation. It produces a “blocky” rendering but can be useful to see the voxel positions. The default value LINEAR uses hardware accelerated bi-linear interpolation. TRILINEAR improves image quality for SoObliqueSlice nodes that are rotated away from the primary axes of the volume (it’s the same as LINEAR for other nodes). MULTISAMPLE_12 is an advanced interpolation algorithm based on antialiasing techniques. It uses staggered samples from 12 neighbors of the sample point to avoid coloring artifacts introduced by the hardware rasterizer. It provides the best image quality but has a small performance penalty because it is implemented using a GLSL shader. MULTISAMPLE_12 applies to SoOrthoSlice, SoObliqueSlice, SoFenceSlice and SoVolumeSkin. MULTISAMPLE_12 does not apply to volume rendering, but SoVolumeRender provides a higher quality mode specific to volume rendering, called cubic interpolation.
"Important"
The slice nodes (except volume geometry) have an alternateRep field, similar to the MeshViz nodes. This field can optionally contain a scene graph which is an “alternate representation” of the node, using only standard texture and faceset nodes. When reading a “.iv” file Open Inventor will automatically use the alternate representation scene graph if it does not recognize the node type. This allows volume slices created in a VolumeViz application to be read and displayed correctly in any Open Inventor-based program, for example SceneViewer, even if that program does not initialize the VolumeViz extension.
The application program can set any scene graph into the alternateRep field before writing an “.iv” file, but this is usually not necessary. VolumeViz can automatically generate an alternateRep scene graph for slice nodes. The setWriteAlternateRep() method in SoVolumeRendering enables this behavior. Open Inventor “.iv” files that contain this field will not be readable by applications using an Open Inventor version less than 4.0. However this field will not be written out unless specifically requested by the application.
Normally when VolumeViz nodes with an alternate representation are read into a VolumeViz-enabled application (i.e., SoVolumeRendering::init() was called), the alternative representation is not stored in the scene graph (to save memory). You can override this behavior using the setReadAlternativeRep() method in SoVolumeRendering
1.13.2