Hybrid Rendering of Dynamic Heightfieldsusing Ray-Casting and Mesh Rasterization

Lucas Ammann∗ Olivier Genevaux∗

Universite de Strasbourg

LSIIT UMR 7005 CNRS-UDS, France

Jean-Michel Dischler∗

Ray

-cas

ting

prec

isio

n High

LowMesh

Figure 1: Rendering of the Como Lake (4096×4096 heightfield) using our method combining mesh renderingand ray-casting. This frameis rendered at 43 Hz on a viewport of 1900×700 px. The right part of the figure depicts the division of theterrain amongst the mesh andray-casting with its four levels-of-precision.

ABSTRACT

This paper presents a flexible hybrid method designed to renderheightfield data, such as terrains, on GPU. It combines two tradi-tional techniques, namely mesh-based rendering and per-pixel ray-casting. A heuristic is proposed to dynamically choose betweenthese two techniques. To balance rendering performance againstquality, an adaptive mechanism is introduced that depends on view-ing conditions and heightfield characteristics. It managesthe pre-cision of the ray-casting rendering, while mesh rendering is re-served for the finest level of details. Our method is GPU accel-erated and achieves real-time rendering performance with high ac-curacy. Moreover, contrary to most terrains rendering methods, ourtechnique does not rely on time-consuming pre-processing steps toupdate complex data structures. As a consequence, it gracefullyhandles dynamic heightfields, making it useful for interactive ter-rain edition or real-time simulation processes.

Index Terms: I.3.7 [Computer Graphics]: Three-DimensionalGraphics and Realism—Raytracing; I.3.6 [Computer Graphics]:Methodology and Techniques—Graphics data structures and datatypes; I.3.8 [Computer Graphics]: Applications

1 INTRODUCTION

Heightfield rendering at interactive frame rates has alwaysbeen animportant topic in computer graphics, whose main application isterrain visualization, where the common representation isa regu-lar sampling of the altitude. Finding out a good trade-off betweenspeed, visual accuracy and flexibility remains the most challeng-ing issue. Some applications, like video games require veryfastframe rates, while others rather require high accuracy, even if framerates are lower, like scientific visualization of 2D scalar fields orgeomatic-related data visualization. Others require thatterrains canbe edited dynamically in real-time.

∗email:{ammann,genevaux,dischler}@unistra.fr

Most of the techniques can be broadly classified into two mainfamilies: mesh-based techniques, which make use of hierarchicalrepresentations, and ray-casting algorithms, which are now mainlyexecuted on GPU. To be practical, mesh-based rendering methodsdo not render raw data and thus often involve pre-processingsteps.As an example, an adaptive mesh reconstruction or the generationof a hierarchical multi-scale structure for applying level-of-detailsmechanisms are often used. Conversely, GPU ray-casting is ableto directly process raw terrain data. The straightforward use of rawdata, without heavy pre-processing, is interesting for interactive ap-plications that involve non-static terrains. Interactiveterrain edi-tion for graphical content creation in the field of virtual landscapedesign is an important example of application. During real-timesimulation processes, such as terrain erosion or ocean waves, thedynamic aspect is also crucial, as well as for scientific visualizationwhere parameters, like transfer functions, must remain editable inreal-time. Our motivation is to improve flexibility by offering aheightfield rendering method which strongly limits pre-processingsand which makes no use of complex data structures, thus allowingfor dynamic terrain manipulations at interactive frame-rates.

Unfortunately, straightforward ray-casting of raw data, whileavoiding any pre-processing, remains too slow to be practical.Speedup techniques further used introduce approximationsandlower fidelity: Dick et al. [5] have shown that a mesh representa-tion still performs better than a ray-casting technique formoderatedata resolution. Yet, mesh based methods tend to smooth reliefsbecause they handle large data sets in a hierarchical way such as forgeometry clipmaps [14].

In this paper, we address such smoothing by combining a meshrepresentation and a GPU based ray-casting rendering. The meshrepresentation uses the full resolution of the data close tothe viewer,while ray-casting rendering is performed further away. Ray-castingprecision is governed by the view distance and relief characteristicsso as too balance quality versus speed, as shown on Figure 1. Theuse of one or the other rendering technique is driven by a heuris-tic based on an analysis of the error induced by ray-casting.Byfully exploiting the GPU and by evaluating the ray-casting error,our method improves the balance between real-time rendering per-

formance and high visual accuracy over existing techniques, stillallowing the data to be edited or dynamically modified.

The key points of our approach can be summarized as follows:

• a hybrid rendering method combining per-pixel ray-castingand mesh rendering, both executed on GPU to provide inter-active frame rates.

• a simple heuristic, based on an error evaluation of the ray-casting rendering, to balance both methods and to maintainhigh visual accuracy.

• a method using only simple data structures, without pre-processing, thus able to handle dynamic heightfields.

The remainder of this paper is organized as follows: in Section 2,we briefly review existing methods for heightfield rendering. InSection 3, we present our rendering method. In Section 4, an anal-ysis of a ray-casting algorithm is proposed and our adaptivemech-anism is described in Section 4.2 with a detailed analysis. Finally,some results are shown in Section 5, before concluding in Section 6.

2 RELATED WORKS

In the following three subsections, we respectively present mesh-based rendering techniques, ray-casting-based renderingand hybridmethods.

2.1 Heightfield rendering with meshesHistorically, the first family of terrain rendering methodsis basedon the use of triangular meshes. To reduce the amount of trian-gles without sacrificing the terrain geometry, these methods usedifferent strategies, such as adaptive level-of-details meshing algo-rithms [7, 8, 13], advanced data loading and caching mechanisms tofully exploit GPU [12, 4, 10], or dedicated compression algorithms[14, 6]. We refer the reader to the overview of Pajarola and Gobbetti[18] for more details concerning these rendering techniques.

A good compromise between rendering quality and performanceis offered by the geometry clipmaps [14]. This simple approachconsists in selecting a level-of-detail in world space based on viewerdistance using a set of nested rectangular regions. It also proposesa compression method associated to a regular mesh rendering.

2.2 Heightfield ray-casting

The second family of heightfield rendering techniques is based onray-casting. These methods were initially developed on CPU[16],but with modern hardware, it becomes possible to execute them onGPU.

Mantler and Jeschke [15] propose a rendering method using aper-pixel ray-casting executed on GPU. This method was devel-oped to integrate some other objects, like trees. There is noadaptivemechanism but an empty space skipping algorithm accelerates theray intersection lookup with the heightfield. Jeong and Han [9] alsopropose a per-pixel rendering of terrains using ray-casting, whereproxy geometry, to initiate ray-casting, is a simplified mesh of theterrain. This process reduces the ray intersection lookup but intro-duces a pre-processing step to build this proxy. If the heightfield isdynamic, this step needs to be recomputed at each frame.

In addition to previously described techniques, while not specif-ically targeting terrain rendering, relief mapping algorithms [20,22, 21] are more focused on adding details to an object surface us-ing a heightfield as input data. This class of algorithms, executedon GPU, computes an approximate intersection between a ray andthe heightfield. To perform a more accurate and faster intersectionlookup, methods such as [2, 19] rely on heavy pre-processing. Butthe major drawback is the important computation time, whichpre-vents the data to be dynamic. Tevs et al. [23] propose a techniqueto accelerate the ray lookup intersection. This algorithm is used and

Heuristicevaluation

+frustum culling

Cells sortingbased on

rendering method flag

MeshrenderingBox

Generation

Ray-casting

Terrain Cells+

min/max

renderingmethod flag+ level-of-precision

height map+

normal map

Terrainupdate

GPU

GPU

GPU

GPU

CPU

Pixel shader

Geometry shader

Heuristic evaluation

Rendering

Frame dependentdata

GPU MemoryPersistent dataGPU Memory

Figure 2: Diagram of our rendering pipeline. Arrows describe dataflow between each step of the whole rendering process and the GPUmemory.

improved by Dick et al. [5] to render large scale terrain split intotiles. In this paper, the authors also demonstrate the viability of ray-casting algorithms to render terrains but conclude that rasterizationtechniques still remain more efficient for small and medium scaleterrains.

2.3 Hybrid techniquesOne way to improve the rendering performance is to combine dif-ferent rendering algorithms, choosing the best performingone fora given situation. In this spirit, Becker et al. [3] were the firstto combine different kinds of relief rendering techniques:BRDF,bump mapping and displacement mapping. Smooth transitionsarethen introduced to avoid popping artifacts when switching betweenthese three representations. Larue et al. [11] also proposea hybridalgorithm to render the small canvas relief of digitized artpaintings.They combine relief mapping with bump mapping and introducean adaptive mechanism which automatically chooses the better ren-dering technique according to the current viewing conditions andpainting relief. We apply such a kind of approach to terrain render-ing, and we combine mesh rendering and ray-casting depending onviewing conditions and landscape data too.

3 HYBRID RENDERING METHOD PRINCIPLES

The principle of our hybrid rendering technique is summarized inFigure 2. The terrain is divided into a regular set of identical squarecells. For each cell, the adaptive mechanism, guided by our heuris-tic that will be described in the next section, chooses the best ren-dering algorithm to use: mesh or ray-casting. The adaptive mecha-nism also adjusts the ray-casting precision amongst predefined lev-els. For each level a given shader is used. To further increasesperformance, frustum culling is performed on cells during this pro-cess. The work-flow is as follows: first, the heuristic is evaluatedfor each cell on the GPU (see top of figure). Then, a read-back from

GPU memory to the main CPU memory is needed to group togetherthe cells that share a common shader. Finally, the data are displayedprecision levels by precision levels (see bottom of figure).

When the content of a cell is rendered using a mesh, vertex dis-placement mapping is performed, using one quad of mesh stored onGPU memory. This quad is designed to match the number of eleva-tion points enclosed in any cell. This quad is overlaid on cells andthe vertex displacement mapping is steadily applied on the verticesof this quad.

When ray-casting is selected, we use the algorithm described byPolicarpo et al. [20]. All the front faces of the box boundingthecontent of the cell are the rendering proxy: for each pixel drawn,a ray is cast and the intersection with the heightfield is computedusing a linear search followed by a binary search. Both stepsareperformed using a fixed number of iterations. Note that a ray canhave no intersection with the heightfield during the traversal of thebox. Proxy boxes are adjusted to the height extend inside thecell,to keep their footprint as tight as possible. To ensure proper conti-nuity across cells boundaries, maximal and minimal height valuesare computed using one pixel overlap with neighboring cells.

It could have been possible to apply a per-pixel precision modu-lation within the ray-casting shader, but we experienced that adapta-tion at cell level performs better due to performance issuesrelatedto dynamic branching on GPU at pixel-level. Therefore, we usea pre-defined fixed number of ray-casting shaders each one corre-sponding to a different level-of-precision.

Since our goal is to handle dynamic heightfields, no speeduptechniques involving many pre-computed data can be used, such assafety zones used for empty space skipping [2, 19].

As can be seen in Figure 2 (right part), our combined renderingmethod requires only minimal extraneous data on top of the height-field data: cell subdivision information (e.g. the cell’s origin) andminimal/maximal height values of its bounding box. When a terrainis evolving dynamically, both minimal and maximal height valuesas well as terrain normals evolve. Hence, these values need to beupdated accordingly. Fortunately, computing minimal and maximalheights for each cell turns out to be a very light process, which canbe done interactively on GPU in parallel to the normals computa-tions. In addition, since the terrain is divided into an independentset of cells, only the altered cells can be updated in case of alocaldeformation or edition, keeping the operation costless.

Since our method targets direct use of heightfield data, it does notmake use of level-of-details techniques. Indeed, using a straightfor-ward approach (direct geometrical mipmapping for example)doesnot provide a sufficient control on the geometrical simplification aswith geometry clipmaps. As a consequence, data over smoothingwould be introduced, as shown in section 5. Using a more complexapproach for the level-of-details mechanism, based on a fineanaly-sis of the data, may reduce the geometrical over smoothing, but therequired complex data structures would be difficult to handle on theGPU, add memory overheads and require pre-processing steps. In-teractive performances may be degraded up to an unacceptable leveltoo. As a consequence, the rendering of dynamic data sets wouldbe severely impaired. Nevertheless, as explained in section 4.3, ifdirect use of heightfield data is not required, implementingsuchmechanism would still be possible. However, even if such multi-resolution technique would be included, no major performance in-crease would be achieved since we use an image based renderingmethod for the faraway areas. Indeed, rendering complexityde-pends on the number of rendered pixels, and is not directly linkedto data size (except for hardware constraints like memory accesslatency, for example). Yet, some aliasing artifacts resulting fromthe mismatched data/screen resolution would certainly be alleviateddue to surface smoothing.

HA : 2048×2048 MB : 4096×4096 SP : 4096×4096

Figure 3: Heightfields used for error evaluation: high amplituderelief (HA), Mont Blanc terrain (MB) and spectrogram (SP).

4 ADAPTIVE MECHANISM

In this section, we describe our heuristic to automaticallychoosebetween the two rendering techniques. Since ray-casting does notguarantee an exact intersection between rays and the heightfieldsurface, it might introduce some visual artifacts. Hence, our heuris-tic must also take into account such artifacts to make them invisibleor to minimize them. In the next subsection, we first study andeval-uate the rendering errors introduced by ray-casting. Basedon thisstudy, we then propose an efficient heuristic.

4.1 Ray-casting Error Analysis

Our motivation is to provide a measure that allows us to evalu-ate the error induced by ray-casting compared to an accurate, full-resolution, mesh rendering with respect to various parameters. Thefollowing parameters are known to be involved in the ray-castingrendering quality: viewing distance and angle, terrain characteris-tics and heightfield intersection lookup precision.

As error measure, we propose to use the distance, along the view-ing ray, between the accurate reference mesh surface and thesur-face rendered using the ray-casting algorithm. Such an error mea-sure is well suited to evaluate ray-casting errors and provides anintuitive interpretation of the rendering accuracy. Indeed, a valueof zero means no error at all, compared to the actual mesh renderedterrain, while the value can become infinite if parts are completelymissed. We conducted many tests and measurements on two ex-treme ray-casting cases, with varying view angles (from grazing toorthogonal) and varying view distances: a very low quality case,using only 5 linear steps and 2 binary refinement steps and a highprecision case, using 64 linear steps and 25 binary refinement steps.

We also evaluated the error on different data sets: a standardterrain data set (the Mont Blanc, denoted MB), a heightfield froma spectrogram (SP) and a synthetic data set (HA) with high am-plitude reliefs (see Figure 3). The spectrogram data set is chosenfor its high frequency details to magnify the rendering technique’sability to preserve small-scale terrain details. Moreoverit featuresa strong anisotropy with many parallel narrow valleys and ridges.The synthetic high amplitude data set is used to characterize thesilhouette preservation of the rendering method.

To evaluate the overall precision of the rendering, a peak signal-to-noise ratio (PSNR) error is computed, for each frame, as follows:

E = 10· log10

(

R2

MSE

)

where the mean squared measured error is derived from the errorseiof all rendered pixels in frameF (with #F , the number of rendered

0% 57%

Error distribution Rendering result

Figure 4: Geometric error of low precision ray-casting versus ref-erence mesh, on spectrogram data set (SP). Error is relativeto theterrain length. PSNR error for this capture is 51.87 dB. 69.5% ofthe pixels have an error less than 1% of the terrain length; 80% lessthan 5% terrain length and 89.5% less than 10% terrain length.

PSNR (dB)

Distance Angle1

2

3

1030

40

50

50

60

70

70

80

90

(a) High amplitude

PSNR (dB)

DistanceAngle0

24

68

1030

50

65

70

7585

90

95105115

(b) Mont Blanc

PSNR (dB)

DistanceAngle0

24

6

1030

50

55

65

70

75

85

90

(c) Spectrogram

Figure 5: PSNR measured for two ray-casting precisions (high pre-cision in red, low precision in blue) on three data sets with varyingview-angles and distances to the viewer.

pixels):

MSE =1

#F ∑i∈F

e2i

and correlated to the terrain bounding box typical lengthR.Figure 4 shows an example of the spatial error distribution of

low precision ray-casting for a grazing view angle. As visible onthis figure, it results in large errors, since some intersections aremissed at crest lines. Consequently, relief silhouettes are altered.These artifacts are reduced to become negligible when ray-castingprecision increases.

As we can see on Figure 5, the major influence on ray-castingquality is the viewing angle. If the terrain is smooth, the error isalmost linearly dependent on this angle. Conversely, the distancedoes not introduce rendering artifacts: the rendering quality is quiteconstant depending on the distance. The relief influence becomesimportant when the relief amplitude is high, as it is the casewithour high amplitude data set: errors are always present even with anear orthogonal view angle.

From our experiments, we see that the size of the terrain doesnothave a direct impact concerning the rendering performance,whichis presented in Table 1. This is related to the fact that ray-casting is

Data setHigh

amplitudeMontBlanc

Spectro-gram

(Data size) (20482) (40962) (40962)Low precision RC 430 360 238High precision RC 76 47 36

Full mesh rendering 26 6.9 7

Table 1: Rendering speed (in Hz) for a grazing view angle on aviewport of 1024×768.

mainly dependent on the number of pixels that are rendered. Ren-dering performance is also directly linked to the precisionof theray/heightfield intersection lookup steps. As shown on Figure 4, ifthe precision is not sufficient, rendering artifacts becomestronglyvisible in the foreground. These artifacts are also more pronouncedwhen the viewing position is moving, since it results in flickeringeffects. As a consequence, low precision ray-casting must be usedcarefully, and a good balance must be determined between qualityand performance.

4.2 HeuristicBased on our observations, we now introduce a heuristic to choosebetween the two rendering techniques in a way that enhances therendering quality without sacrificing the rendering performance.

As we showed previously, ray-casting can achieve high render-ing quality or high rendering performance depending on the inter-section lookup precision. Moreover mesh rendering with a num-ber of triangles matching the full resolution of the data offers themost accurate rendering. At close range, mesh rendering is also themost efficient rendering method since a single triangle projects onnumerous pixels, actual performance depending on graphicshard-ware. Taking this fact into account, we propose to use a thresholdbased on terrain screen coverage to choose between mesh render-ing and ray-casting. Thus, we define the thresholdT according tohardware capabilities: when mesh rendering becomes more effi-cient than ray-casting, the heuristic should select mesh rendering.Intuitively, this threshold should be compared to the triangle’s areaon screen.

For each cell, the associated box is projected onto the screen.Then, its footprint area is approximated by computing, in screenspace, the areaA of the bounding rectangle of the 8 corners of thebox. This value summarizes the distance from the camera and themaximum relief variation (represented with the minimum andmax-imum height values) inside the cell. In fact, since we are interestedin the triangles footprint on screen,A is divided by the number ofterrain samplesS contained within the cell (thusS = n2 wherenis equal to the number of samples on the cell width). IfA/S isgreater than the threshold parameterT , then mesh rendering shouldbe used:

{

A/S > T ⇒ mesh renderingA/S ≤ T ⇒ ray-casting rendering

If ray-casting is chosen for the current cell, then its precision mustbe further determined.

To improve rendering performance, we want to use the least pos-sible ray-marching steps. But, as described in Section 4.1,ray-casting introduces some artifacts at grazing view angles, which wewant to avoid, as much as possible. As previously shown, heightamplitude of a terrain cell is also an important parameter: if thiscell represents an important part of the view, ray-casting precisionshould be increased. In addition, the ray-casting absoluteprecisioncan be decreased according to the distance without affecting therendering quality.

Thus, we incorporate the viewing angle, the distance betweencamera and cell, and the height amplitude of the cell in our heuris-tic. For a given box, we propose the following formula to compute

the level-of-precision:

L =min(db,dmax)

dmax− (h ·cosθ )

whereh is the height of the box (elevations of the heightfield aresupposed to be contained between 0 and 1),θ is the angle betweenthe viewing ray and the vertical at the center of the box anddb isthe distance between the center of the box and the camera. Thevaluedmax is computed withdmax = k · dBB, wheredBB representsthe maximal possible value fordb, which corresponds to the diago-nal length of the terrain bounding box in world space. The heuristicis decomposed into two terms. The first one controls the variationsdue to the viewing distance. The second one controls the variationsrelated to the viewing aspect (i.e. the viewing angle compared tothe heightfield base plane). The heuristic depends on a parame-ter k which includes a terrain size normalization factor and whichfinally modulates levels-of-precisions distribution according to thedistance between the cell and the camera.

Finally, L values are evenly distributed amongst the ray-casting levels-of-precisions,L = 0 representing the highest level-of-precision.

4.3 Implementation notesTo test our method, we implemented it using OpenGL on a standardPC. All measures were performed using a NVIDIA GeForce GTX280 graphics card with 1 GB of graphical memory.

For each cell, only heightfield data (elevation and normal) andthe elevation bounds are required. These data are stored in two tex-tures whose layout match the terrain one. This layout was chosento keep our implementation simple but this prevents us from han-dling extremely large data sets, as our implementation onlyallowsheightfields which entirely fit into GPU memory to be rendered.Nevertheless, since the data are accessed cell by cell (for visiblecells) during rendering, it would be possible to further adda stream-ing mechanism to dynamically upload required data into the GPUmemory on demand.

As previously described in section 3, in order to allow dynamicheightfields rendering, no pre-processing is performed. Conse-quently, no optimization technique for ray-casting, like empty spaceskipping mechanisms [2, 19, 23], is included. Yet, it is conceivableto integrate such kind of techniques. However, memory footprintwould be increased and handling dynamic heightfields would berestricted, or even become impossible.

4.4 Heuristic parameters analysisAs the heuristic defined previously is based on several parameters,the influence of these parameters is now analyzed.

The cell size has an influence on the rendering performance. Weobtain the highest frame rates for box sizes varying between502

and 1282 samples, as shown on Figure 6. In fact, when box size be-comes too small, rendering performance decreases: too manycellsmust be rendered using ray-casting which involves increasing over-draw: some pixels are drawn multiple times in neighboring boxes.When box size increases, the meshed surface becomes more im-portant and slower to render (when many cells are rendered usingthis algorithm). Moreover, a higher overdraw also occurs duringthe ray-casting pass.

Table 2 shows the influence of the number of different ray-casting levels-of-precision. To measure these rendering timings,we use the Puget Sound data set (4096×4096 px) with a box sizeof 75×75 pixels. The scene is rendered using a varying numberof levels-of-precision: the number of steps ranges from 64 to 6 forlinear search, and from 50 to 5 for binary search. This parameteronly affects ray-casting, so the mesh rendering timing is identicalfor all configurations. Moreover, the time elapsed to evaluate thelevel-of-precision heuristic is constant since the computation is the

0

10

20

30

25 50 75 100 128 150 200 250 300 350 400

Re

nde

ring

timin

gs(m

s)

Cell size (# samples)

Heuristic evaluation Mesh rendering Ray-casting rendering

Figure 6: Influence of cell size on rendering timing for the Mont-Blanc data set (MB).

# LOP Heuristicevaluation

Meshrendering

Ray-casting

Totalrendering

2 0.38 2.38 10.80 13.614 0.42 2.33 12.13 14.956 0.38 2.33 13.04 15.808 0.38 2.33 13.83 16.6010 0.38 2.35 14.66 17.45

Table 2: Influence of the number of levels-of-precisions (LOP) onthe rendering performances. Timings are in ms.

same. On the contrary, the ray-casting rendering pass timing in-creases with the number of levels-of-precision. This overhead can-not clearly be traced back to a specific part of the rendering,butmight be the consequence of increasing shader context switching.Experimental results show that rendering quality does not signifi-cantly increase along with the number of levels-of-precision sincethe lowest and highest precision levels both stay the same. Theseresults also show that four levels-of-precisions provide the best bal-ance between rendering speed and quality.

Our heuristic uses different parameters to allow an adaptation tothe data and allows a user to set the trade-off between rendering pre-cision and speed. The parameterT , used to define whether or nota mesh is used, mainly selects the foreground area of the height-field, and allows one to improve the rendering quality for thesearea: whenT increases, the mesh coverage of the heightfield be-comes more important. The parameterk, used to adapt the heuristicto the relief characteristics, acts on the precision distribution of theray-casting. Ifk is low, more parts of the heightfield are renderedusing a low level-of-precision, so rendering error increases.

Figure 7 shows the influence of these parameters on the ren-dering speed and quality. Quality is expressed with PSNR errorand terrain silhouette rendering precision (wrong pixels). This fig-ure shows values measured on several frames of a fly-through overtwo different data sets. As we can see, the rendering qualityisstrongly linked to the parameterk which adapts the ray-casting dis-tribution. Indeed, when using a lowk parameter, more cells arerendered using a low-precision ray-casting, so the rendering qualityis decreased but the rendering speed is increased. With regard tothe parameterT , its impact on rendering quality and speed is lessimportant thank. The rendering speed is slightly lower when thisparameter increases but the quality is not significantly enhanced.

However, we can notice, on very high frequencies data sets likethe spectrogram data set, that ray-casting misses more pixels, espe-cially for grazing view angles. This is confirmed on Figure 7 witha higher proportion of wrong pixels on some frames.

5 RESULTS AND COMPARISON WITH GEOMETRY CLIPMAPS

Some rendering results and a thorough comparison with geometryclipmaps [14] are now presented. The ability of our method tohan-

PS

NR

(dB

)

PS

NR

(dB

)

Rendering speed (in ms)Rendering speed (in ms)00 5 10 5 2020 25 30 35 4040 4560

60

62

64

66

68

70

7072

74

76

78

80

80

80

82

100 12050

55

65

75

85

A : GC n = 511, lod = 11B : GC n = 127, lod = 13C : T = 75,k = 1D : T = 75,k = 1.25E : T = 75,k = 1.5F : T = 100,k = 1G : T = 100,k = 1.25H : T = 100,k = 1.5

A, B

A, B

C, FC, F

D, G

D, G

E, H

E, H

Puget SoundSpectrogram

(a) Rendering quality (PSNR value)

%of

rend

ere

dpi

xels

%of

rend

ere

dpi

xels

Rendering speed (in ms)Rendering speed (in ms)0

00

05

5

10 5 2020 25 30 35 4040 4560 80 100 120

0.2

0.4

0.6

0.8

1.0

1.0

1.2

2

4

4.5

3.5

3

2.5

1.5

0.5

A : GC n = 511, lod = 11B : GC n = 127, lod = 13C : T = 75,k = 1D : T = 75,k = 1.25E : T = 75,k = 1.5F : T = 100,k = 1G : T = 100,k = 1.25H : T = 100,k = 1.5

A, B

A, B

C, FC, F

D, G

D, G

E, H

E, H

Puget SoundSpectrogram

(b) Wrong pixels

Figure 7: Comparison between geometry clipmaps (GC) and ourmethod for varying parameters. (a) PSNR error value (y axis) is expresseddepending on the rendering speed (x axis). Each point of the plots represents PSNR and speed values for a single frame of a fly-through overthe spectrogram data set (left) and over the Puget Sound (right). (b) proportion of wrong pixels expressed depending on the rendering speedfor the same frames.

dle dynamic heightfields is also presented.

5.1 Rendering quality and performances

Figure 1 shows a rendering result for the Como Lake data set ofresolution 4096× 4096 px. The colors highlight the distributionof the levels-of-precision of the ray-casting algorithm. It clearlyshows that our heuristic is guided by relief features to define theprecision of the ray-casting. We usedT = 70 andk = 1.30 for acell size of 1282 samples and four levels-of-precision (linear/binarysteps): 55/25, 32/15, 16/10, 8/5. Using this configuration and aviewport of 1024×768 px, a frame rate between 40 and 150 Hz isobtained, depending on the viewing position. When the same dataare rendered using a full resolution mesh, with the same viewingconditions, the frame rate varies between 5 Hz and 9 Hz.

Compared to a reference mesh rendering, on Figures 8 and 9, ourrendering method well preserves small reliefs and, consequently,does not smooth reliefs with high frequencies details.

A major drawback using hybrid techniques is popping artifactswhich occur at the transitions between different renderingtech-niques and levels-of-precision. However, with our method,givensufficient precision on ray-casting no popping artifacts are visible.Our method does not introduce cracks between cells renderedusingdifferent levels-of-precisions. All cells rendered as a mesh use thesame full resolution terrain samples thus, no T-junction isever cre-ated at the boundary between two meshed cells. At mesh-ray tracedboundaries, no crack is produced either because ray tracingoperateson the full resolution data too: entry point of the ray in the proxy

box is always coherent regarding to the mesh rendered in the neigh-boring cells because both use the same sampling of the terrain andthe same linear interpolation between samples. It is an advantagecompared to level-of-details mechanisms which combine mesheswith different resolutions: they frequently need to deal with cracksat the boundary of terrain areas rendered using different resolutionsand rely to complex re-meshing systems or adaptive tessellations.

Since no geometrical level-of-details mechanism is used, ourmethod does not intrinsically mitigate aliasing artifacts. However,experimental results show that artifacts are limited to theless accu-rate levels-of-precisions. In fact, cells rendered with mesh or with ahigh ray-casting level-of-precisions do not suffer from aliasing. Asthe full mesh is used for the closest part of the terrain, suitable pa-rameters can keep the triangles big enough to avoid these artifacts.Still, in the background, minor aliasing cannot be easily alleviatedbecause no antialiasing mechanism is used.

5.2 Comparison with clipmaps

We compare our method to the GPU handled geometry clipmaps[1], with the following parameters:n = 511, 11 levels-of-details,and an alpha transition ofn/10. Since the clipmaps only use adistance based level-of-details scheme, small relief features are oversmoothed, as we can see on Figure 9. The error is mainly located onthe crest lines. This is also confirmed on the top of Figure 7 wherewe can see better PSNR error values for our rendering technique.To enhance the over smoothing of the geometry clipmaps and itseffect on the PSNR measure, we also use more degraded settings

Figure 8: Rendering comparison between our method (left) and areference mesh rendering (right).

(a) k = 1.0, T = 100,PSNR ≈ 68 (b) k = 1.5, T = 100,PSNR ≈ 78

(c) Geometry clipmapsn = 511, 11LOD, PSNR ≈ 59

Figure 9: Rendering quality comparison between our method (a)and (b) for varyingk parameter values and the geometry clipmaps(c). Excerpt from Figure 8.

for the geometry clipmaps (n = 127 and 13 levels-of-details).Since our heuristic takes into account relief features, it better

preserves them. For data with high relief amplitudes or highrelieffrequencies, silhouette errors are also mostly avoided with our tech-nique, while they remain more present with geometry clipmaps, asillustrated on Figure 9. In fact, compared to a reference mesh ren-dering (Figure 8), some pixels are not rendered and some othersare rendered at a wrong place, especially on crest lines. These vi-sual observations are corroborated by the numerical PSNR error, asshown on the top of Figure 7. The bottom of the Figure 7 also quan-tifies this phenomena. As we can see on this figure, our method,depending on the heuristic parameters, minimizes these renderingerrors.

Several experiments on various terrain data sets have shownthatour method provides better results on data sets with high frequen-cies details: geometry is well preserved without any smoothing ofthe small details, maintaining real time rendering frame rates.

5.3 Dynamic heightfields

One key point of our method is its straightforward handling of dy-namic heightfields. Our method does not introduce any dependen-cies between cells for the rendering. As a consequence, local defor-mations of the data remain local to the data and do not propagateto the whole data. Global modifications are also possible andcouldbe performed in real time, depending on the data set size and thecomplexity of the deformation process. No height amplitudecon-

Figure 10: On top and middle, Puget Sound data set (4096×4096px) before (left) and after (right) interactive erosion (≈ 35 - 45 Hz)and editing. On bottom, Puget Sound data set with wave simulationprocess (≈ 35 - 45 Hz).

Fra

me

rate

(Hz)

Without data update processWith erosion process

With wave simulation

Time30

40

50

60

Figure 11: Speed rendering comparison between our method, ourmethod with an erosion process and our method during a wave sim-ulation on the Puget Sound terrain. For both erosion and wavesim-ulations, height data are updated every 100 ms.

straints are applied to the deformations since the elevations remainbetween 0 and 1.

As examples, we have implemented a real-time erosion mech-anism [17], an interactive terrain stamping and a simple oceanwave simulation. For the erosion mechanism and wave simulation,heightfields are entirely updated. For the terrain stamping, only themodified area of the heightfield is updated. Results are shownonFigure 10.

As shown on Figure 11, we are able to maintain real-time perfor-mances while the erosion process or the wave simulation are run:only the cell minimum and maximum altitudes are retained over theregular erosion process. For the interactive terrain stamping, onlythe minimum and maximum altitudes of the modified cells need tobe updated.

6 CONCLUSIONS AND FUTURE WORKS

In this paper, we have introduced a new hybrid method designedto render heightfield data sets with a good balance between speed,quality and flexibility, the latter allowing for terrains tobe dynamic.

We combined two different rendering methods: a mesh renderingand a ray-casting algorithm using different levels-of-precision. Tocombine these methods, we proposed a heuristic that modulates therendering precision according to the distance, viewing angle and re-lief features in order to maintain high rendering performance with-out visual quality loss. This heuristic also takes into account a user-given quality factor to balance between triangle projections whereno error is committed and ray-based intersections.

Our rendering process requires neither complex pre-processingsteps nor sophisticated accelerating data structures. It directly usesraw heightfield data. This allows us to edit terrains and to applya mechanism to update the whole data like an erosion simulationprocess or a simple wave simulation, both in real-time. Comparedto other terrain rendering techniques, our method is simpleto useand easily allow dynamic heightfield data sets.

The rendering quality we obtain is good compared to standardterrain rendering methods, such as geometry clipmaps, since weuse mesh and high precision ray-casting for the most salientrelieffeatures. Crest lines and small features of the relief at thehori-zon are also well preserved. However, as previous research hasalready shown, ray-casting remains globally slower than adaptivemesh based rendering, which hinders one to obtain high framerates.This can be considered as the main counterpart of improved flexi-bility and rendering quality. But flexibility and quality ofthe ren-dering is important for some kinds of applications like scientificdata visualization or geomatic applications. Finally, ourmethodprovides better results than standard methods to render relief de-tails with high frequencies maintaining a real-time frame rate. Thecell division of the terrain and the independence between the cellsprovide a high degree of flexibility of our method. As a conse-quence, our method allows one to easily select parts of the terrainswhich are rendered or not. This might prove useful for applicationswhich should render different parts of the terrain using differentalgorithms (to handle non-heightfield structures of a terrain, for ex-ample).

For the moment, no streaming mechanism is implemented tohandle very large data sets. But since we use a cell-subdivision ofthe height data, the rendering of large data sets seems possible, pro-vided we define an adequate loading and caching strategy, similarlyto Dick et al. [5].

Finally, in our future works, we also would like to study aliasingproblems alongside some form of simple and lightweight level-of-details mechanisms. Indeed, heightfields rendering algorithms gen-erally suffer from aliasing, especially in faraway areas. We believea ray-casting algorithm is inherently well suited to address accu-rately aliasing, for instance using adaptive over-sampling process.

ACKNOWLEDGEMENTS

We would like to thank the reviewers for their helpful comments.Puget Sound and Grand Canyon data sets courtesy of USGS.

Mont-Blanc, Como Lake and Dolomiti data sets courtesy ofAim@Shape. Como Lake texture manually stitched from data de-livered by Bing maps (c© Microsoft Corp., Harris Corp. EarthstarGeographics LLC)

REFERENCES

[1] A. Asirvatham and H. Hoppe. Terrain rendering using gpu-based ge-ometry clipmaps. InGPU Gems 2, chapter 2. Addison-Wesley Pro-fessional, 2005.

[2] L. Baboud and X. Decoret. Rendering geometry with relief textures.In GI ’06: Proceedings of Graphics Interface 2006, pages 195–201.Canadian Information Processing Society, 2006.

[3] B. G. Becker and N. L. Max. Smooth transitions between bump ren-dering algorithms. InSIGGRAPH ’93, pages 183–189. ACM, 1993.

[4] P. Cignoni, F. Ganovelli, E. Gobbetti, F. Marton, F. Ponchio, andR. Scopigno. BDAM - batched dynamic adaptive meshes for highper-

formance terrain visualization.Computer Graphics Forum, 22:505–514, 2003.

[5] C. Dick, J. Kruger, and R. Westermann. GPU ray-casting for scal-able terrain rendering. InProceedings of Eurographics 2009 - AreasPapers, pages 43–50, 2009.

[6] C. Dick, J. Schneider, and R. Westermann. Efficient geometry com-pression for GPU-based decoding in realtime terrain rendering. Com-puter Graphic Forum, 28(1):67–83, 2009.

[7] M. Duchaineau, M. Wolinsky, D. E. Sigeti, M. C. Miller, C.Aldrich,and M. B. Mineev-Weinstein. Roaming terrain: Real-time optimallyadapting meshes. InProceedings of Visualization ’97, pages 81–88.IEEE Computer Society Press, 1997.

[8] H. Hoppe. Smooth view-dependent level-of-detail control and its ap-plication to terrain rendering. InProceedings of Visualization ’98,pages 35–42. IEEE Computer Society Press, 1998.

[9] T. S. Jeong and J. Han. Per-pixel rendering of terrain data. InCompu-tational Science - ICCS 2006, 6th International Conference, volume3993 ofLecture Notes in Computer Science, pages 40–47. Springer,May 2006.

[10] R. Lario, R. Pajarola, and F. Tirado. Hyperblock-quadTIN : Hyper-block quadtree based triangulated irregular networks. InProceedingsIASTED International Conference on Visualization, Imaging and Im-age Processing (VIIP), pages 733–738, 2003.

[11] F. Larue, L. Ammann, and J.-M. Dischler. A pipeline for the digi-tisation and the realistic rendering of paintings. In8th InternationalSymposium on Virtual Reality, Archaeology and Cultural Heritage.Eurographics, november 2007.

[12] J. Levenberg. Fast view-dependent level-of-detail rendering usingcached geometry. InVIS ’02: Proceedings of the conference on Vi-sualization ’02, pages 259–265. IEEE Computer Society, 2002.

[13] P. Lindstrom and V. Pascucci. Visualization of large terrains madeeasy. InVIS ’01: Proceedings of the conference on Visualization ’01,pages 363–371, Washington, DC, USA, 2001. IEEE Computer Soci-ety.

[14] F. Losasso and H. Hoppe. Geometry clipmaps: Terrain rendering us-ing nested regular grids. volume 23, pages 769–776. ACM, 2004.

[15] S. Mantler and S. Jeschke. Interactive landscape visualization usingGPU ray casting. InGRAPHITE ’06: Proceedings of the 4th interna-tional conference on Computer graphics and interactive techniques inAustralasia and Southeast Asia, pages 117–126. ACM, 2006.

[16] F. K. Musgrave. Grid tracing: Fast ray tracing for height fields. Re-search report no. rr-639, Yale University Dept. of ComputerScience,1988.

[17] J. Olsen. Realtime procedural terrain generation. October 2004.[18] R. Pajarola and E. Gobbetti. Survey on semi-regular multiresolution

models for interactive terrain rendering. 23(8):583–605,2007.[19] F. Policarpo and M. M. Oliveira.GPU Gems 3, chapter 18 Relaxed

Cone Stepping for Relief Mapping. Addison-Wesley, 2007.[20] F. Policarpo, M. M. Oliveira, and J. L. D. Comba. Real-time relief

mapping on arbitrary polygonal surfaces. InI3D ’05: Proceedingsof the 2005 symposium on Interactive 3D graphics and games, pages155–162. ACM, 2005.

[21] L. Szirmay-Kalos and T. Umenhoffer. Displacement mapping on theGPU - state of the art.Computer Graphics Forum, 27(6):1567–1592,2008.

[22] N. Tatarchuk. Dynamic parallax occlusion mapping withapproximatesoft shadows. InI3D ’06: Proceedings of the 2006 symposium onInteractive 3D graphics and games, pages 63–69. ACM, 2006.

[23] A. Tevs, I. Ihrke, and H.-P. Seidel. Maximum mipmaps forfast, ac-curate, and scalable dynamic height field rendering. InSI3D ’08:Proceedings of the 2008 symposium on Interactive 3D graphics andgames, pages 183–190. ACM, 2008.