SoHeightFieldGeometry Class Reference
[Nodes]

VolumeViz Height field data node More...

#include <VolumeViz/nodes/SoHeightFieldGeometry.h>

Inheritance diagram for SoHeightFieldGeometry:
SoVolumeData SoDataSet SoVolumeRendering SoNode SoFieldContainer SoBase SoRefCounter SoTypedObject

List of all members.

Public Member Functions

virtual SoType getTypeId () const
 SoHeightFieldGeometry ()

Static Public Member Functions

static SoType getClassTypeId ()

Public Attributes

SoSFDouble undefinedValue

Detailed Description

VolumeViz 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:

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

SEE ALSO

SoHeightFieldRender, SoHeightFieldProperty, SoMultiDataSeparator, SoConverter

See related examples:

HorizonIsolines, HorizonGpuCompose, SimpleHorizon, SimpleHorizonInMemory, SimpleHorizonRGBA


Constructor & Destructor Documentation

SoHeightFieldGeometry::SoHeightFieldGeometry (  ) 

Constructor.


Member Function Documentation

static SoType SoHeightFieldGeometry::getClassTypeId (  )  [static]

Returns the type identifier for this class.

Reimplemented from SoVolumeData.

virtual SoType SoHeightFieldGeometry::getTypeId (  )  const [virtual]

Returns the type identifier for this specific instance.

Reimplemented from SoVolumeData.


Member Data Documentation

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.


The documentation for this class was generated from the following file:

Open Inventor Toolkit reference manual, generated on 12 Feb 2024
Copyright © Thermo Fisher Scientific All rights reserved.
http://www.openinventor.com/