Class SoHeightFieldGeometry

  • All Implemented Interfaces:

    public class SoHeightFieldGeometry
    extends SoVolumeData
    Height field data node. SoHeightFieldGeometry defines a uniform grid in the XY plane whose vertices are height (Z) values stored in 2D LDM format (any LDM data set with the Z dimension equal to 1). Storing only height values is a very efficient way to represent a surface and LDM supports 8 and 16 bit integer data in addition to float (and other types). Adding the combination of LDM data management with advanced GPU features provides a way to handle extremely large surfaces. Just as with volume data, LDM uses tiles of data and multiple levels of resolution to enable interactive frame rates even for data sets that cannot fit in system memory.

    SoHeightFieldGeometry is derived from SoVolumeData and serves a similar purpose in the scene graph, providing a reference to an LDM data set which will be loaded as needed by rendering nodes, specifically SoHeightFieldRender in this case. It also supports an "undefined" value which will be rendered as holes in the grid. The geometry is given by the inherited field fileName. The given file must be an LDM file built by the LDM converter (see SoConverter). For use with SoHeightFieldRender the data set must have a depth (Z dimension) of exactly 1. The undefined value can be specified with the -u option of the converter or explicitly by setting the undefinedValue field.

    Data set values are converted to height values in 3D space in two ways depending on the data type:

    • Integer values are normalized between [0,1] ([-1,1] for signed types) based on the range of values for the specific data type. For example, for UNSIGNED BYTE values the range 0..255 is mapped to 0..1.
    • Floating point values are not normalized (are used "as is").

    Extent in 3D space

    A standard SoVolumeData 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 and always contains the current extent values. 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 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 and you can still control the bounding box using an SoTransform (or similar) node. To scale or offset the height values, put a transform node in the scene graph before the SoHeightFieldGeometry node. For example, to scale the height values by a factor of 2, you could use an SoScale node with the scaleFactor field set to (0,0,2).

    File format/default:

    HeightFieldGeometry {

      allocateResourceOnRender false
      data NODATA 0 0 0 UBYTE 8
      dataSetId 1
      dataTransform NULL
      extent -1 -1 -1 1 1 1
      fileName ""
      usePalettedTexture true
      texturePrecision 0
      undefinedValue NaN
      useCompressedTexture true
      useExtendedData false
      usePalettedTexture true
      useSharedPalettedTexture true

    See Also:
    SoHeightFieldRender, SoHeightFieldProperty, SoMultiDataSeparator, SoConverter
    • Field Detail

      • undefinedValue

        public final SoSFDouble undefinedValue
        Vertices with this value won't be rendered by the SoHeightFieldRender.
        Default is NaN (Not a Number) which means that this value is not taken into account. Otherwize, value must be in agreement with data type.
    • Constructor Detail

      • SoHeightFieldGeometry

        public SoHeightFieldGeometry()