The SoHeightFieldGeometry( C++ | Java | .NET ) node is analogous to (and derived from) SoVolumeData( C++ | Java | .NET ). This node defines a uniform grid in the XY plane whose vertices are height (Z) values. Storing only height values is a very efficient way to represent a surface. The data is a “volume” containing any valid scalar data type, but the Z dimension of the volume must be 1. The volume data can be loaded in any of the usual ways (see Section 1.2, “Data”)
Height field data supports an "undefined" value which will be rendered as holes in the surface. The undefined value can be specified using the “-u” option of the LDM converter or using the undefinedValue field (which overrides the value loaded from an LDM file). The default undefined value is NaN (Not a Number), which effectively means there is no undefined value by default.
Data set values imply height values in 3D space in one of two ways, depending on the data type:
Integer values are normalized to the floating point range [-1,1] for signed types and [0,1] for unsigned types. Normalization is based on the full range of values for the specific data type. For example, for UNSIGNED BYTE values the range 0..255 is mapped to 0..1 and for UNSIGNED_SHORT the range 0..65535.
Floating point values are not normalized (they are used "as is").
A standard SoVolumeData( C++ | Java | .NET ) node has no intrinsic "extent" in 3D. The extent of the volume is initially defined by the values returned from the volume reader (normally from the extent tag in the LDM file header). The extent field is initialized with these values from the reader. The application can modify the extent of the volume by changing the values in the extent field. (Note that the actual bounding box of the volume in 3D is the volume extent modified by any transform nodes in the scene graph.)
SoHeightFieldGeometry( C++ | Java | .NET ) however only uses the X and Y parts of the extent field. The Z extent of the surface in 3D is completely defined by the values in the data set. So the X and Y values in the extent field are the actual extent, but the Z values are not meaningful and changing the Z values in the extent field has no effect. Note that you can always get the current bounding box (X, Y and Z) using an SoGetBoundingBoxAction( C++ | Java | .NET ) and you can still modify the bounding box using a transform node, for example SoTransform( C++ | Java | .NET ) or SoScale( C++ | Java | .NET ).
To integrate height field rendering with slice and volume rendering, for example placing a horizon surface inside a seismic volume, you may have to:
Set the height field X and Y extent to match the 3D extent of the data volume,
Scale or offset the height values to match the 3D extent of the data volume, and/or
Rotate the height field so the Z axis aligns with the vertical axis of the data volume.
To scale, rotate or offset the height values, put a transform node in the scene graph before the SoHeightFieldGeometry( C++ | Java | .NET ) node. For example, to scale the height values by a factor of 2, you could use an SoScale( C++ | Java | .NET ) node with the scaleFactor field set to (1,1,2).