Terrain Overview

Here is a list of standard resolutions for Earth, Mars and Moon, when using geo-referenced cubemap datasets.

A raster is a regular grid of samples, where each sample holds a number of values, one for each of the data layers:

Rasters are represented by the IHeightmap interface.

The inherent pixel coverage semantic of rasters is pixel-is-point, but a IHeightmap may optionally use pixel-is-area, for example when wrapping a geo-referenced image during geodata processing.

Rasters always have a size of 2^N+1 by 2^N+1 samples, where 8 ≤ N ≤ 30.

Rectangular rasters are represented with the smallest fitting square raster, using zero coverage for all samples outside of the data rectangle.

Cubemap rasters are built from six individual rasters (one for each cubemap face), where the corner samples are shared by three rasters and the edge samples are shared by two rasters.

Rasters may be tied to a geo-reference, so that each sample can be mapped to a geo-location, usually on Earth.

When increasing the size of a raster (N+1), new samples (red) may be interpolated from the existing samples (white), for example by using Catmull-Rom splines.

When decreasing the size of a raster (N-1), all odd rows and columns are deleted.

These transformations are applied dynamically at runtime, when consuming raster data for terrain rendering.

Pyramid data is basically a tree of equally sized square image tiles, often referred to as tiled maps.

Well-known examples are BingMaps, GoogleMaps and OpenStreetMaps.

The idea is to start with a single image tile that covers the region of interest. For web maps this is usually the Earth in Pseudo-Mercator projection. Then, the root tile is split evenly into four sub-tiles, which quadruples the number of pixels that cover the region of interest, which effectively halves the resolution (metres per pixel).

Tile splitting is repeated until the region of interest is represented with the desired resolution. The resulting tile tree is not necessarily balanced, usually different resolutions are desirable for different regions, for example low resolution for oceans, medium resolution for rural regions and high resolution for urban regions.

The inherent pixel coverage semantic of pyramids is pixel-is-area.

The bottom-most level of a pyramid always has a size of 2^N by 2^N pixels, where 0 ≤ N ≤ 30. The number of pyramid levels is a function of this full size and the tile size:

levels = log2(full-size / tile-size) + 1

Cubemap pyramids are built from six individual pyramids (one for each cubemap face), where the corner and edge pixels of adjacent faces touch, but are not shared, as it is the case with rasters.

Pyramids may be tied to a geo-reference, so that each pixel center can be mapped to a geo-location, usually on Earth.

The following figure shows an example pyramid with 3 levels, a tile size of 4 and a full size of 16:

The Tinman 3D SDK provides two types of pyramid data: pixel pyramids and texel pyramids. Pixel pyramids provide the source image data for terrain rendering. At runtime, pixel pyramid data may be consumed in flexible ways, for example scaling, slicing, combining or reprojection. As the last processing step, pixel data may be encoded into a GPU-ready texture format, such as BC3, which yields the texel pyramid.

Regarding GPU-based 3D terrain rendering, tiled maps have an inherent problem with texture filtering at tile borders, which is not present when doing typical 2D rendering (web maps, for example). Given a perspective 3D view on a terrain, the GPU will perform anisotropic texture filtering on the texture tiles. At the tile border, the filter kernel is clamped (when using one texture per tile) or bleeds into adjacent tiles (when using a texture atlas), which results in visually apparent artefacts.

To avoid these visual artefacts, pyramids may use padding, which resamples each tile so that a defined amount of pixel data of neighbouring tiles appears within the tile. Then, texture coordinates are adjusted at runtime. There is a one-time computational overhead per tile on the CPU side, which can easily be remedied by using standard caching. There is no overhead on the GPU side.

Raster and pyramid data is fed into a processing pipeline which ultimately produces the resources that are required for 3D rendering, such as triangle meshes and textures. Processing is usually distributed between pre-processing and on-the-fly processing at runtime, depending on the needs of the application.

Raster data as well as pyramid data is allowed to be mutable. When the data is modified, the processing pipeline runs incrementally and produces updated 3D resources. This process is quick and may be used interactively at runtime, for example to put surface decal imagery onto the terrain.

Using mutable raster and pyramid data is not suitable for highly dynamic data, such as:

In these cases, dynamic terrain overlays may be used:

A dynamic overlay is basically a GPU texture that is rendered on top of the terrain mesh, re-using the existing 3D geometry. The content may be sourced from images or produced at runtime, for example by using GPU render targets.

The APIs provide different methods for putting dynamic overlays onto the terrain surface. For details, please refer to Surface Decals.

Using elevation raster data to create terrains has several limitations, for example:

To overcome these limitations, the Tinman 3D SDK allows to use displacement raster data, in addition to elevation data.

Displacement information that has been fetched from raster data is built into the 3D geometry of the terrain mesh and may be consumed by the application, for example by picking or planting geometry.

Material-based texturing uses GPU tessellation to apply a second layer of displacement, for close-up views at ground level.

Displacement information that has been sourced from GPU textures cannot be consumed by the application, unless data is read back from the GPU.

Raster and Pyramid data may be generated using pseudo-random noise functions:

The Tinman 3D SDK builds terrain meshes that classify as Right-triangulated Irregular Nets (RTINs). An RTIN is a TIN that contains only right-isosceles triangles.

Starting with two root triangles (which form a so called diamond) per cubemap face, triangles are split recursively along their longest edge. This is commonly referred to as longest-edge bisection.

By splitting triangles according to a view-dependent visibility criterion (for example, the screen pixel error that would be introduced by not splitting the triangle), the terrain mesh exhibits continuous level-of-detail, capturing near and far parts of the terrain equally well.

Splitting a triangle introduces a T-junction (see the red vertex with the white border in the figure above), unless its longest edge lies on the border of a rectangular mesh. To resolve the T-junction, a forced split must be performed on the adjacent triangle once (if it has the same size) or twice (if it is bigger). The forced split may trigger another forced split, which creates a chain of recursion that may lead up to the root triangles.

Terrain meshes using RTIN / CLOD have certain advantageous properties for realtime rendering:

For cubemap terrain meshes, six RTINs are used, one for each cubemap face.The data structures are built in a way so that all forced triangle splits seamlessly propagate to adjacent faces, without requiring any additional logic.

In the figure above, when treating the ARGL as the root diamond of a cubemap face, forced splits (i.e. following LL, LR, RL, RR for the center vertex with the blue border) propagate to the root diamond of the adjacent cubemap face.

For each terrain mesh, certain hierarchical data structures are maintained, which are intended to speed up spatial queries.

The data structure that is used to represent the CLOD mesh inherently captures the triangle hierarchy that results from longest-edge bisection as well as the quadtree hierarchy of pyramid tiles. Moving through the mesh structure and switching between mesh elements (i.e. vertices, pyramid tiles, triangles) is very efficient.

Aligned with the quadtree of pyramid tiles, the following hierarchy of spatial data is maintained:

For realtime 3D terrain rendering, terrain data is kept in various memory buffers and is processed by different CPU threads and the GPU. This section introduces the data buffers and explains the overall data flow. For additional details, please refer to Low-level Terrain API.

At runtime, several threads are used to access terrain data and to process CLOD terrain meshes:

The shadow buffer ensures that the render thread and the GPU threads will never access any data that is being updated by the refinement thread. Also, it ensures that the refinement thread does not delete any data that is still being used by the other threads. This makes it possible to use shared memory buffers and to perform efficient GPU updates.

The triangulation process is responsible for extracting leaf triangles from a CLOD mesh, either for the whole mesh or for specific quadtree tiles. Several triangulation modes exist, to accomodate different use-cases, such as realtime 3D rendering or 3D mesh export.

A typical operation on a CLOD mesh performs a top-down traversal of its quadtree while analyzing the spatial hierarchy, in order to optimize performance by skipping irrelevant mesh parts. During traversal, individual quadtree tiles may be flagged as culled or marked, which creates a filtered quadtree. It is possible to have multiple independent filter states of the same quadtree and to copy flags between them.

It is common to chain operations, where the subsequent operation consumes the flags that have been output by the preceding operation. For example: remove invisible terrain parts by adding cull flags in the first operation, then perform texturing of the visible terrain parts by adding mark flags to textured quadtree tiles in the next operation and finally perform triangulation of the marked terrain parts in the last operation, for GPU rendering.

This API provides a set of loosely coupled components, which need to be set up and combined carefully, in order to implement terrain features. While this API provides the greatest amount of flexibility, it also requires considerable effort to get things done.

For a conceptual overview of this API, please refer to the Terrain Mesh section.

Using this API involves these basic steps:

At this level, it may be necessary to use custom components that interface directly with the surrounding application infrastructure, in order to manage and access GPU resources (IVertexBuffer, IIndexBuffer, etc.). If the built-in components are not suitable, you may implement your own components. Please refer to the source code of the following SDK components to find examples on how to implement custom GPU components:

The following examples and tutorials involve this API:

This API wraps the features of the Low-level Terrain API in a small number of terrain-specific domain classes, which represent the primary concepts of terrain handling, such as the terrain mesh, texture layers and surface decals. With this API, only terrain-specific features are available.

Using this API involves these basic steps:

This API is built on top of the GPU Rendering abstraction layer and thus uses IGraphicsContext objects for GPU access.

Please refer to the source code of the following SDK components to find examples on how to implement a graphics context:

The domain classes in this API impose several assumptions and feature decisions, which may not be suitable for all use-cases. If this is the case with your application, you may consider falling back to the Low-level Terrain API or adjusting the source code according to your needs.

The following examples and tutorials involve this API:

This API wraps the features of the High-level Terrain API and augments them with a framework for building interactive 3D scenes, using the commonly known scene-graph approach. With this API, many non terrain-specific features become available.

For details on how to use the Scene API, please refer to Scene Overview page and the How To Do section.

The following examples and tutorials involve this API:

This API encompasses those features that process geodata or other non-terrain assets, either up-front in a pre-processing step or on-the-fly at runtime. Data processing involves import to Tinman 3D as well as export to other 3rd-party software.

For details on geodata processing, please refer to the Geodata Examples and the Geodata Processing page.

The following examples and tutorials involve this API:

This section explains how to perform automatic planting of geometry on the terrain surface, for example grass, trees, rocks or other objects. Usually, this involves geometry instancing on the GPU side.

Planting is performed adaptively, taking into account the Terrain Data and the current Terrain Mesh structure.

For terrain editing, dynamic planting may be used to provide quick feedback for the given planting options.

For terrain rendering, static planting is favorable: here, planting is performed up-front on static terrain mesh chunks.

This section shows how the different terrain APIs relate to the GPU Rendering abstraction layer.

There are various ways to modify and deform the Terrain Mesh at runtime, which classify as one of the following:

The Tinman 3D SDK provides a robust mechanism for performing cascaded shadow mapping for large terrains on a global scale.

The Terrain Mesh provides spatial acceleration data structures on the CPU, which may be used to perform various kinds of spatial queries.

This section explain how the APIs can be used for performed spatial queries.

The geometry of a Terrain Mesh can be reused to render decals onto the terrain surface, without the need to generate additional geometry.

The Tinman 3D SDK provides two methods for texturing the terrain surface:

The first method sources texture data from one or more ITexelPyramid objects and performs unique texturing.

The second method uses the Material layer to perform artificial texturing by mixing the specified material textures.

Material-based texturing may be well-suited for close-up views, near the terrain surface. Unique texturing may be a good choice for more distant terrain parts.

Culling refers to the process of excluding certain parts of the Terrain Mesh from further processing.