This node defines a shape which is the intersection of the volume data defined by an OIV.VolumeViz.Nodes.SoVolumeData node and the 3D shape defined by an OIV.Inventor.Nodes.SoBufferedShape node. The shape defined by this intersection is colored using the data values from the current OIV.VolumeViz.Nodes.SoVolumeData node and color map from the current OIV.LDM.Nodes.SoTransferFunction node.

The shape defined by this intersection is textured using the data from the current OIV.VolumeViz.Nodes.SoVolumeData node and OIV.LDM.Nodes.SoTransferFunction node. The OIV.VolumeViz.Nodes.SoVolumeBufferedShape.interpolation field controls how the texture is interpolated. Texture coordinates are automatically computed for each vertex based on its position relative to the 3D extent of the volume. If texture coordinates are specified, they are ignored.

This node can be used to create custom "slices" through the volume, for example a cylinder slice. It can be considered a generalization of the OIV.VolumeViz.Nodes.SoOrthoSlice, OIV.VolumeViz.Nodes.SoObliqueSlice, OIV.VolumeViz.Nodes.SoFenceSlice, etc features. But note:

• Compared to an equivalent standard slice (e.g. OIV.VolumeViz.Nodes.SoOrthoSlice), the rendering may be slightly different due to positioning and interpolation.

• The standard slices (e.g. OIV.VolumeViz.Nodes.SoOrthoSlice) have "two-sided lighting" enabled by default as a convenience. This is not true for volume geometry nodes (which have the same default as their corresponding standard geometry node), so the "back" side of the geometry will not be lighted unless you enable two-sided lighting using an OIV.Inventor.Nodes.SoShapeHints node.

When set to false, the OIV.VolumeViz.Nodes.SoVolumeBufferedShape.clipGeometry field allows rendering of the portion of the geometry that does not intersect the volume data. This portion is not textured and is rendered as a regular OIV.Inventor.Nodes.SoBufferedShape.

This node uses 3D texturing and is not available if the hardware does not support this feature.

OIV.Inventor.Nodes.SoBufferedShape provides fields for:

• Vertices

• Indices (optional)

• Colors (optional)

• Normals (optional)

• Texture coordinates (optional)

OIV.VolumeViz.Nodes.SoVolumeBufferedShape is useful to manage the rendering of large geometry, provide application control over where the data is stored (CPU or GPU) and to integrate rendering with the Open Inventor computing framework (through the OIV.Inventor.Devices.SoBufferObject classes).

OIV.VolumeViz.Nodes.SoVolumeBufferedShape can render many types of geometric primitives including points, lines, quads and triangles. (A single type must be specified per instance of OIV.VolumeViz.Nodes.SoVolumeBufferedShape.) You specify the type of primitive in the SoSFEnum field shapeType.

OIV.VolumeViz.Nodes.SoVolumeBufferedShape can render multiple primitives of the same type. You can specify the number of vertices (or indices if provided) to use for each primitive in the OIV.Inventor.Fields.SoMFInt32 field numVertices (similar to OIV.Inventor.Nodes.SoFaceSet).

You can also use the primitive restart feature to define multiple indexed strip shapes, for example TRIANGLE_STRIP or LINE_STRIP. The end of each primitive is marked by a special index value in the index buffer and this value can be specified in the primitiveRestartValue field. The behavior is similar to the "-1" value that can be used in Open Inventor indexed shape nodes like OIV.Inventor.Nodes.SoIndexedFaceSet, but is implemented on the GPU.

NOTE:

• Primitive restart must be explicitly enabled using the primitiveRestartEnabled field.

• Check availability of primitive restart using OIV.Inventor.Nodes.SoShape.IsPrimitiveRestartAvailable(OIV.Inventor.Misc.SoState).

The geometry and its attributes must be stored in buffer objects (see OIV.Inventor.Devices.SoBufferObject). The buffer objects can be SoGLBufferObjects stored directly on the graphics board or SoCpuBufferObjects stored in system memory. This allows the application to control what data is stored where.

If lighting is enabled (there is no OIV.Inventor.Nodes.SoLightModel node or the model field of the OIV.Inventor.Nodes.SoLightModel is set to PHONG) and the normalBuffer field is not set, then normal vectors are automatically generated, similar to other geometry nodes. Normal generation is affected by the creaseAngle field of the OIV.Inventor.Nodes.SoShapeHints node if the vertices are NOT indexed. If the vertices are indexed the creaseAngle is forced to PI in order to have smooth surface rendering. It is not possible to display sharp edges by using indexed vertices if the normals are not set by the application. It is possible to disable normal generation (if for example the normals are generated by a geometry shader) by setting the useNormalsGenerator field to false. Note that normal generation is disabled in some cases. See the limitations section. If no normal vectors are specified or generated, and lighting is enabled, the primitive may not be rendered correctly.

OIV.VolumeViz.Nodes.SoVolumeBufferedShape provides fields to describe the content of each buffer, e.g. the data type and number of components in each buffer, as well as how to access the buffers, e.g. the offset into the buffer and "stride" separating data values in the buffer. The default values for offset and stride assume that the vertices, normals, etc are each in a separate buffer. However setting appropriate offset and stride allows, for example, vertices and normals to be interleaved in a single buffer. In this case the same buffer would be set into both the vertexBuffer and normalBuffer fields.

To disable computing the bounding box, which can take a long time with very large geometry, use the OIV.Inventor.Nodes.SoBBox node to specify a pre-computed bounding box.

Limitations

• Projections: The projections used in the VolumeViz mechanism are not handled by OIV.VolumeViz.Nodes.SoVolumeBufferedShape.

• Lighting: If there is no normalBuffer the normals are generated by Inventor. The crease angle (field of OIV.Inventor.Nodes.SoShapeHints) is not considered by the normal generator if the vertices are indexed (crease angle is PI). So if the application wants to render sharp edges on its shape, it must use the vertexBuffer without indices in the indexBuffer.

• Transparency: If there is no color buffer, making the entire shape transparent using an OIV.Inventor.Nodes.SoMaterial node works as usual. However if there is a color buffer with RGBA values, note that Open Inventor does not currently check the color buffer for transparency (alpha values < 1). So in this case the OIV.VolumeViz.Nodes.SoVolumeBufferedShape will not be considered transparent geometry (even if there are alpha values < 1) and may not be rendered correctly. You can force Open Inventor to handle the shape as transparent geometry by putting an OIV.Inventor.Nodes.SoMaterial node with non-zero transparency before it in the scene graph.

• Normal generation: Automatic generation of normal vectors is ONLY enabled when:

  • The vertexComponentsCount field is set to 3 (default),

  • The vertexComponentsType field is set to OIV.Inventor.SbDataType.DataTypes.FLOAT (default),

  • The primitiveRestartEnabled field is set to false (default), and

  • The primitives are faces (i.e. neither points nor lines).

• OIV.Inventor.Actions.SoGetPrimitiveCountAction: When using the primitive restart feature, the triangle/line count returned by the OIV.Inventor.Actions.SoGetPrimitiveCountAction will not be accurate.

• Concave polygons: Unlike (for example) OIV.Inventor.Nodes.SoFaceSet, OIV.VolumeViz.Nodes.SoVolumeBufferedShape does not automatically tesselate concave or complex polygons. Such primitives may not be rendered correctly.

• OIV.Inventor.Actions.SoWriteAction: OIV.VolumeViz.Nodes.SoVolumeBufferedShape can be saved to and restored from a .iv file just like any other Open Inventor node. However, during the read operation any OpenGL buffer objects (OIV.Inventor.Devices.SoGLBufferObject) in the file will be created as CPU buffers (OIV.Inventor.Devices.SoCpuBufferObject) if there is no OpenGL context bound during the read operation.

• Material binding (etc): OIV.VolumeViz.Nodes.SoVolumeBufferedShape effectively only supports per-vertex and per-vertex-indexed binding of materials, normals and texture coordinates.

• Simplification: OIV.VolumeViz.Nodes.SoVolumeBufferedShape is ignored by the "simplify" actions (OIV.Inventor.Actions.SoShapeSimplifyAction, OIV.Inventor.Actions.SoGlobalSimplifyAction, OIV.Inventor.Actions.SoReorganizeAction).

Notes:

• 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 rendering nodes like OIV.VolumeViz.Nodes.SoVolumeBufferedShape. However the same transformation must be applied to the volume data node and all volume rendering nodes associated with that volume. So effectively any transformation nodes that affect the volume must be placed before the volume data node.

• 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.

FILE FORMAT/DEFAULT

VolumeBufferedShape {

clipGeometry	true
offset	0
interpolation	LINEAR
useNormalsGenerator	true
shapeType	TRIANGLES
numVertices	0
vertexBuffer	NULL
vertexComponentsCount	3
vertexComponentsType	OIV.Inventor.SbDataType.DataTypes.FLOAT
vertexStride	0
vertexOffset	0
normalBuffer	NULL
normalComponentsType	OIV.Inventor.SbDataType.DataTypes.FLOAT
normalStride	3 * sizeof(float)
normalOffset	0
indexBuffer	NULL
indexType	OIV.Inventor.SbDataType.DataTypes.UNSIGNED_INT32
indexOffset	0
colorBuffer	NULL
colorComponentsType	OIV.Inventor.SbDataType.DataTypes.FLOAT
colorStride	0
colorOffset	0
colorComponentsCount	3
texCoordsBuffer	NULL
texCoordsComponentsType	OIV.Inventor.SbDataType.DataTypes.FLOAT
texCoordsStride	0
texCoordsOffset	0
texCoordsComponentsCount	2
primitiveRestartEnabled	false
primitiveRestartValue	-1

}

ACTION BEHAVIOR

OIV.Inventor.Actions.SoGLRenderAction Draws primitives based on the current coordinates, normals, materials, drawing style, and so on.

OIV.Inventor.Actions.SoRayPickAction Picks primitives based on the current coordinates and transformation. Details about the intersection are returned in an OIV.Inventor.Details.SoFaceDetail.

OIV.Inventor.Actions.SoGetBoundingBoxAction Computes the bounding box that encloses all vertices of the face set with the current transformation applied to them. Sets the center to the real center of the bounding box: center{ (xmax + xmin) / 2, (ymax + ymin) / 2, (zmax + zmin) / 2 }

OIV.Inventor.Actions.SoCallbackAction If any triangle callbacks are registered with the action, they will be invoked for each successive triangle generated from each face in the set.

Reference