Online demos

Seismic Horizon

Seismic Horizon (Height Field)

Open Inventor includes many features specifically implemented to enhance seismic interpretation applications. Let's take a look at the Height Field rendering system for seismic horizon surfaces. A horizon surface typically represents the transition between two regions of rock having different properties.  Note that height field rendering is useful in other application areas, for example, to represent terrain with height mapped to color or with “draped” imagery.  The height field rendering system includes support for memory management, reducing triangle count to maintain performance, color mapping based on a property field, blending colors from multiple property fields, 'undefined' value, cell outline rendering, and more.  In addition, height fields can be used as input to other powerful features such the Horizon Probe.

Update: Open Inventor 10.8 introduces two improvements in the height field rendering system.

  1. Height as a property: Height fields can now be color mapped using the height values directly (without creating a property field).
  2. Vertex shifting: A shader function is now available that allows the application to "shift" the vertex positions away from the implicit grid locations. Learn more...


Horizon challenges

The height field rendering system is a solution to the challenge of rendering very large triangle surfaces interactively.  A horizon surface is commonly defined by a regular grid of time/depth values. Because the grid normally has the same line/crossline dimensions as the seismic volume, the resulting geometry can easily contain three or four million triangles for each surface with three float values for each vertex. And a typical project needs to visualize multiple surfaces.  In a seismic interpretation application, we normally want to use as much memory as possible for the volume data. The first challenge is that storing the surface as a triangle mesh uses too much memory, especially on smaller instances in a cloud deployment. The second challenge is that rendering large triangle meshes at full resolution may not be possible at interactive frame rates. We could use multiple levels of detail.  But at some point, users may need to see the full resolution data and also, users dislike the visual (and performance) "jump" between levels.  There is a better way.

Height Field is the solution

Height Field: Because a horizon surface is usually defined on a regular grid with exactly one height value for each grid position, we can represent the surface as a "height field".  In a height field, the XY locations are implicit and we only need to store the Z (height) values.  This automatically reduces the memory requirement to one-third of what a full triangle mesh would require.

Multi-resolution tiles: To address the rendering performance challenge, the first step is to take advantage of the LDM multi-resolution tiled data manager.  This is the technology that allows Open Inventor to interactively render volume data much larger than the available CPU and GPU memory.  We consider height field data to be a "flat" volume, i.e. with Z dimension of 1, similar to the way we handle very large images.  VolumeViz manages the data in chunks called "tiles" and constructs a multi-resolution pyramid.  The bottom level is full-resolution data and each level higher is a lower resolution.  As usual, the tile pyramid can be created and stored in a pre-processing step or created on-the-fly. With this data structure, we have random access to any part of the data.  We can access any resolution level or a combination of resolution levels.

Mixed resolution rendering: The next step is to take advantage of Open Inventor's ability to do "mixed resolution" rendering of height field (and volume) data.  This is how we avoid the undesirable features of level-of-detail processing.  We do not need to choose a single resolution for the entire height field. Open Inventor can use high resolution data close to the camera, where the user is "looking". And use low(er) resolution data farther away, where the loss of detail is not noticeable.  Lower resolution data tiles generate fewer triangles.  So we can use different resolution levels to adjust the total number of triangles being rendered to maintain an interactive frame rate.  This also makes the solution scale with the performance of the GPU.  In other words, you can render more triangles by using a faster GPU.

GPU tesselation: The final step is to take advantage of the parallel processing power of the GPU.  It turns out that we don't need to send triangles to the GPU.  We can conserve GPU memory by only sending the height values.  We then use a modern GPU feature called the "tesselation shader" to dynamically create the triangles to be rendered.  If the user "zooms in" on one part of the horizon, we automatically use a higher resolution version of the data and generate more triangles.  The height field renderer also considers the pixel resolution of the screen.  Once the triangle size is smaller than one pixel, there is no need to load a higher resolution version of the data.


Horizon Vertex Shifting

By definition, height field vertices are defined on an implicit regular grid.  Open Inventor 10.8 now provides a powerful option to work around this limitation.  It is now possible to apply an XYZ offset to each vertex using a shader function that executes on the GPU during the triangle generation.  Use cases include geographic projections, mis-aligned coordinate systems, etc.

Here is a simple height field surface with normal rendering:

Here is the same surface with the vertices warped around the curvature of a sphere.  This is an exaggerated example of course, but it demonstrates the generality of the vertex shifting feature.

Applications can choose how to pass the offset values to the shader. In some cases it is not necessary to specify a precise offset for every vertex.  In such a case the application could store the offset values in textures.  The GPU will automatically do interpolation when accessing values in a texture.  As a result the field of offset values can be specified at lower resolution than the actual height field.