GPU Tessellation: We Still Have
a LOD of Te rrain to Cover
onio Ramires Fernandes and Bruno Oliveira
Terrain rendering has come a long way from the days where all data ﬁt in the graphics
memory to algorithms that deal with massive amounts of information that do not
ﬁt in the system’s RAM. Nowadays, a full-blown terrain engine has to deal with out-
of-core issues: a ﬁrst step of the level of detail (LOD) might happen in the CPU to
determine which data goes to the GPU, and a second step of LOD may be required
to draw all those triangles at interactive rates.
In this chapter we are going to explore how OpenGL 4.x can boost performance
in this last step. The algorithms presented will use GPU tessellation for shader-based
LOD and view-frustum culling.
Although LOD can substantially reduce the amount of geometry rendered, it
may also cripple the ﬁdelity of the representation. An approach will be introduced
to render heightmap-based terrains, which can be included in most of the available
terrain-rendering engines, that captures in a simple process the irregularities of a
terrain, maintaining a very high level of visual ﬁdelity to the original data.
Previous knowledge on the subject of GPU tessellation is assumed. See Chapter 6
or “Programming for Real-Time Tessellation on GPU” [Tatarchuk et al. 09], for an
introduction to the subject.
146 II Rendering Techniques
10.2 Rendering Terrains with OpenGL GPU
The goal of this section is to present a heightmap-based, fully tessellated terrain ren-
dering implementation, upon which the LOD solutions will grow (see Figure 10.1).
We assume that the heightmap is a regular grid, represented by a greyscale image
loaded as a texture. However , the terrain size is not limited by the texture ’s size, as
height values between texels can be sampled. The GPU has dedicated hardware for
sampling, such as GLSL texture* functions, according to the sampler or texture
sampler state. The terrain size, in terms of grid points, is, therefore, theoretically
unlimited. To avoid the almost ﬂatness of the regions represented by the sampled
points, noise-based approaches can be used to provide high-frequency detail.
The terrain size, in terms of physical units, can be further parameterized by deﬁn-
ing a grid spacing; in other words, the number of units between two consecutive
points in the ﬁnal grid.
To render the terrain, we use the new primitive introduced with tessellation,
the patch. A patch can cover as many grid points as the maximum tessellation
levels permitted by hardware, a square grid of 64 quads in the current OpenGL 4.0
hardware.Thisdeﬁnesapatchas65× 65 vertices, as the edges of patches are shared
between adjacent patches. To render a terrain, we deﬁne a grid of such patches. As
an example, to render a terrain of 8K × 8K points, a grid of 128 × 128 patches
is required. Other patch sizes are possible, but the reported tests (shown later in
Figure 10.9), show a per formance penalty when using smaller patches.
Since the terrain grid is a highly regular structure, only one vertex to deﬁne a
patch is needed (e.g., the lower left corner). The regular nature of the terrain’s grid
allows the developer to compute all other patch elements based solely on this vertex.
The ﬁnal vertex positions, texture coordinates, and normals will be computed in the
The patch positions are deﬁned as if the terrain were to be drawn in a normalized
square, ranging from 0 to 1. A translation and scale operation will be applied in the
tessellation evaluation shader to place the terrain where n eeded.
Figure 10.1. Full tessellation (left); high LOD (middle); low LOD (right).