Visual Comput (2008) 24: 139–153DOI 10.1007/s00371-007-0180-1 O R I G I N A L A R T I C L E

Yotam LivnyNeta SokolovskyTal GrinshpounJihad El-Sana

A GPU persistent grid mappingfor terrain rendering

Published online: 15 November 2007© Springer-Verlag 2007

Y. Livny (�) · N. Sokolovsky ·T. Grinshpoun · J. El-SanaDepartment of Computer Science,Ben-Gurion University of the Negev,Beer-Sheva, Israel{livnyy, netaso, grinshpo,el-sana}@cs.bgu.ac.il

Abstract In this paper we presentpersistent grid mapping (PGM),a novel framework for interactiveview-dependent terrain rendering.Our algorithm is geared toward highutilization of modern GPUs, andtakes advantage of ray tracing andmesh rendering. The algorithm main-tains multiple levels of the elevationand color maps to achieve a faithfulsampling of the viewed region. Therendered mesh ensures the absence ofcracks and degenerate triangles that

may cause the appearance of visualartifacts. In addition, an externaltexture memory support is providedto enable the rendering of terrains thatexceed the size of texture memory.Our experimental results show thatthe PGM algorithm provides highquality images at steady frame rates.

Keywords Terrain rendering ·Graphics processors · Multiresolutionhierarchies

1 Introduction

Interactive rendering of terrain datasets has been a chal-lenging problem in computer graphics for decades. Terraingeometry is an important component of various visual-ization and graphics applications ranging from computergames to professional flight simulators. The need for accu-rate visualization has led to the generation of large terraindatasets that exceed the interactive rendering capabilitiesof current graphics hardware. Moreover, the rendering ofdense triangulations on the screen can cause undesirablealiasing artifacts. Since level-of-detail rendering managesto decrease the geometric complexity and reduce aliasingartifacts, it seems to provide an appropriate framework forinteractive rendering of large terrain datasets.

Several level-of-detail approaches have been developedfor interactive terrain rendering. Traditional multiresolu-tion and view-dependent rendering algorithms rely on theCPU to extract the appropriate levels of detail which aresent to the graphics hardware for rendering in each frame.In these approaches, the CPU often fails to extract theframe’s geometry from large datasets within the durationof one frame. In addition, communication between the

CPU and graphics hardware often forms a severe trans-portation bottleneck. These limitations usually result innon-uniform or unacceptably low frame rates.

Ray-tracing approaches generate quality images oflarge terrain datasets by shooting rays from the viewpointthrough the pixels of the viewport and computing theirfirst intersection with the terrain surface. The values offinal-image pixels are computed based on the color andnormal at intersection points. In such a scheme, the render-ing time is determined by the number of shot rays and thecomplexity of computing the first intersection. To adoptthis approach for interactive terrain rendering, one needsto reduce the number of shot rays and to simplify or ac-celerate computing of ray-terrain intersection. Reducingthe number of shot rays may deprive some pixels from re-ceiving accurate values, which often causes unacceptableimage quality.

Current graphics hardware provides common func-tionality for both vertex and fragment processors. Thisfunctionality is useful for generating various effects [16],such as displacement mapping and multitexturing. Thesesignificant improvements in graphics hardware neces-sitate the development of new algorithms and tech-

140 Y. Livny et al.

niques to utilize the introduced processing power andprogrammability.

In this paper, we present the persistent grid map-ping (PGM) technique, a novel framework for interactiveterrain rendering (see Fig. 1). Our algorithm takes a dif-ferent approach from previous techniques and as a re-sult, achieves a twofold advantage: it utilizes the benefitsof ray-tracing and mesh-rendering while reducing theirdrawbacks. In each frame, PGM samples the terrain byshooting rays through selected pixels on the viewport,and computing their first intersection with the terrain sur-face. However, rather than assigning the sampled valueson the image plane, we triangulate the ray-terrain inter-section points I to generate a continuous mesh, which isthen rendered using the graphics hardware. Triangulat-ing the points I is easily performed by triangulating thepixels P on the 2D image plane through which the rayspass. It is true as a result of the one-to-one matching be-tween I and P. We refer to the triangulation of these pixelson the viewport as the sample grid. To simplify comput-ing the ray-terrain intersection, we find the intersectionpoint between a ray and the terrain base-plane (z = 0).Then, the height value selected from the elevation mapat the intersection point is used to create a vertex on theterrain surface. The mesh generated using ray-base-planeintersection may differ from the mesh generated using ray-terrain intersection, by a small offset. To overcome thisoffset problem, we shoot additional rays through virtualpixels, such that the mesh generated using ray-base-planeintersection, includes the visible region of the terrain.

Our algorithm is geared toward high utilization ofmodern graphics hardware by generating and renderinga mesh that matches the rendering capabilities of thegraphics hardware. In addition, the sampling of the ter-rain by fast ray shooting is executed within the GPU.The vertex processor extracts the height component of theterrain from elevation maps at the ray-base-plane intersec-tion point and assigns it to the appropriate vertex of thesampled mesh. A similar procedure is executed in the frag-

Fig. 1. View of the Grand Canyon area generated by the PGM al-gorithm

ment processor to extract the color components for eachfragment. Our algorithm maintains multiple levels of theelevation and color maps to achieve faithful sampling ofthe visible region. To avoid multiple-texture binding, it en-codes different level-of-detail maps into one texture. Inaddition, an external texture memory support is providedto enable the rendering of large terrain datasets that exceedthe texture memory size.

PGM provides steady frame rates independent of ter-rain size as a result of rendering meshes of the same com-plexity in each frame. The rendered mesh ensures theabsence of cracks and sliver/degenerate triangles, and itssize is adapted to match the rendering capability of thegraphics hardware. Moreover, the perspective ray shoot-ing remeshes the visible region of the terrain in a view-dependent manner.

In the rest of this paper, we first overview relatedwork in the area of terrain rendering with emphasis onGPU-based algorithms. Then, we present our algorithmand its external texture memory support, followed by im-plementation details and experimental results. Finally, wedraw some conclusions and suggest directions for futurework.

2 Previous work

In this section we overview closely related work in level-of-detail terrain rendering. To simplify the presentation,we categorize these approaches based on the hardwareorientation of their processing.

CPU-oriented processing. These algorithms purely relyon CPU computations and random-access memory to se-lect the appropriate geometry which is sent to the graphicshardware in each frame. Some of these algorithms havebeen developed specifically for terrain rendering, whileothers have targeted general 3D models.

Irregular mesh algorithms represent terrains as trian-gulated meshes. They usually utilize temporal coherenceand manage to achieve the best approximation of the ter-rain for a given triangle budget. However, these algorithmsrequire that the mesh maintain adjacency and validate re-finement dependencies in each frame. Some hierarchiesuse Delaunay triangulation to constrain the mesh [8, 36],while others use less constrained multiresolution hierar-chies with arbitrary connectivity [10, 14, 19, 31].

Regular level-of-detail hierarchies are usually more dis-crete as a result of working on regular grids or quadtrees.To simplify the memory layout and to accelerate the meshtraversal, these algorithms use a restricted quadtree triangu-lation [2, 34], triangle bintrees [13, 27], hierarchies of righttriangles [15], or longest-edge bisection [28]. However, up-dating the mesh in each frame prevents the use of geometrycaching and efficient rendering schemes.

A GPU persistent grid mapping for terrain rendering 141

To reduce CPU load and use efficient renderingschemes, several approaches partition the terrain intopatches at different resolutions. Then, at real-time theappropriate patches are selected, stitched together, andsent for rendering [18, 34, 35]. Cignoni et al. [7] and Yoonet al. [43] have developed similar approaches for gen-eral 3D models. The main challenges of patch-basedapproaches are to select the appropriate patches quicklyand to stitch their boundaries seamlessly. Although thereare no geometric modifications, the communication be-tween the CPU and the graphics hardware forms a seriousbottleneck.

Utilizing video cache. To overcome the bottleneck of com-munication, several algorithms that utilize geometry cachehave been introduced. Some algorithms [5, 6, 24, 26, 41]use the video memory to cache triangulated regions, whileothers maximize the efficiency of the cache by usingtriangle strips [20]. The huge texture maps, which of-ten accompany terrain datasets, have motivated Tanneret al. [40] to introduce the texture clipmaps hierarchy,and Döllner et al. [12] to develop general texture hierar-chies. These techniques enable fast transition of geometryand texture to the graphics hardware. However, the cachememory is limited, thus large datasets may still involvecommunication overhead.

GPU-oriented processing. Frameworks for programmablegraphics hardware have been suggested by [11, 17, 25, 29,32], but have not been implemented for the GPU. Never-theless, the forecast of future hardware has led to noveldesigns that favor many simple computations over a fewcomplicated ones.

The advances in graphics hardware technology andGPU programmability have led to the development ofvarious algorithms. Losasso et al. [30] and Bolz andSchröder [4] use the fragment processor to perform meshsubdivision. Southern and Gain [39] use the vertex pro-cessor to interpolate different resolution meshes in a view-dependent manner. Wagner [42] and Hwa et al. [21] renderterrain patches at different resolutions using GPU-basedgeomorphs. Schneider and Westermann [37] reduce thecommunication time by using progressive transmission ofgeometry.

Several approaches based on the uniform grid havebeen developed to utilize GPU functionality and texturememory. Kryachko [23] uses vertex texture displacementfor realistic water rendering, while Johanson [22] projectsa grid onto a water surface. However, both of these algo-rithms focus on generating water effects rather than sam-pling datasets. Dachsbacher and Stamminger [9] modifythe grid in a procedural manner according to camera pa-rameters and terrain features.

The geometry clipmaps algorithm [1] renders the sur-face triangulation layout composed of tiles of variousresolutions. In each frame, the visible part of the triangu-

lation is sent to the GPU and is modified according to theuploaded elevation and color maps. However, this algo-rithm does not perform local adaptivity, and the transitionbetween levels of detail is not smooth and may result incracks. These cracks are resolved by inserting degeneratetriangles which may lead to visual artifacts.

3 Our algorithm

In this section we present our algorithm for interactive ter-rain rendering that leverages advanced features of modernGPU, such as programmability, displacement mapping,and geometry caching. The throughput of current GPU isenough to cover a frame-buffer with pixel-size triangles atinteractive rates, and vertex processing is catching up withthe pixel fill rate. Therefore, a screen-driven tessellation ofa terrain, where all triangles are nearly pixel-size, wouldefficiently utilize these advances.

Our algorithm generates a sample grid, whose reso-lution is determined by the rendering capabilities of thegraphics hardware. The working window (viewport) is sel-dom resized, and hence the sample grid remains fixed overa large number of frames (and usually over the entire navi-gation session). For that reason, we shall refer to this samplegrid as the persistent grid. The programmable GPU mapsthe persistent grid from the viewport onto the terrain base-plane as shown in Fig. 2. Then, it modifies the mappedpersistent grid according to the terrain surface by fetchingheight and color values from texture memory. The distri-bution of the persistent-grid vertices is not constrained – itcould be uniform, non-uniform, or even a general irregu-lar grid. For example, a focus-guided triangulation of thevisualized terrain could be achieved by using a sphericalpersistent grid with a parameterized subdivision.

The persistent behavior enables caching the grid invideo memory, available even in modest graphics hard-ware. Such caching manages to remove the severe com-munication bottleneck between the CPU and GPU bytransmitting the generated persistent grid only once, andnot in each frame. In addition, it eliminates annoying vari-

Fig. 2. Mapping of the persistent grid onto the terrain base-plane

142 Y. Livny et al.

ations on frame rates by rendering the same number ofpolygons – the persistent grid – in each frame.

3.1 Persistent grid mapping

The mapping of the persistent grid onto the terrain base-plane (z = 0) is performed, similar to [22], by shootingrays from the viewpoint through the vertices of the per-sistent grid, and computing their intersection with the ter-rain base-plane. The vertex Gij on the persistent grid ismapped to the point Pij on the terrain base-plane by usingEq. 1, where V is the viewpoint, and vz and gz are the zcoordinates of the viewpoint and the persistent-grid ver-tex Gij , respectively:

Pij = V + vz

vz − gz(Gij − V ) (1)

Programmable vertex processors in current GPUs pro-vide the ability to access the graphics pipeline and al-ter vertex properties. The simplicity and compactness ofEq. 1 facilitate implementation of ray shooting within thevertex processor. Figure 3 illustrates the mapping of thepersistent-grid vertex Gij to the terrain surface vertex Tij ,which is performed by executing the following steps:

1. The coordinates of the persistent-grid vertex Gij andthe viewpoint V are used to determine the point Pij

– the intersection of the ray VGij with the terrain base-plane – using Eq. 1.

2. The x and y coordinates of Pij are used to fetch theheight value from the elevation map.

3. The mesh vertex Tij , on the terrain surface, has thex and y coordinates of the point Pij and the fetchedheight value as the z coordinate.

In the fragment processor, similar computations areperformed for each fragment to extract its color value fromthe color map.

3.2 Camera restriction

The mapping of the persistent grid onto the terrain base-plane works fine whenever the camera aims toward the ter-

Fig. 3a,b. The translation of persistent grid vertices to terrain sur-face vertices. a Mapping the persistent grid onto the terrain base-plane. b Fetching height values from the elevation map and com-posing mesh vertices

rain base-plane. However, this constraint does not alwayshold, and rays may not intersect the base-plane. We shallrefer to rays that intersect the terrain base-plane as valid,and to rays that are parallel to the base-plane or pointingupward from it (rays do not intersect the base-plane) asinvalid rays. Omitting invalid rays (thus, discarding poly-gons mapped by these rays) wastes computational powerwithout contributing to the final image. Nevertheless, themore severe problem of our sampling scheme is that thesampled region may be offset from the visible region. Anextreme case of this offset problem may lead to miss-ing close peaks when the viewer is flying low, as shownin Fig. 4a.

To avoid the generation of invalid rays, we use anadditional camera – the sampling camera – which is des-ignated for sampling terrain data and generating meshgeometry. Rendering the generated geometry is performedwith respect to the parameters of the viewing camera.We denote by view angle of the camera, the acute anglebetween the horizontal plane and look-at vector of thecamera. The view angle of the sampling camera Asam iscomputed using Eq. 2, where Aview is the view angle of theviewing camera, and FOV is the viewing camera’s field ofview angle. We use ε, as an infinitesimal value, to avoidthe generation of invalid rays.

Asam ={

Aview, if |Aview| > FOV/2;FOV/2+ ε, otherwise.

(2)

In such a scheme, the sampling camera has the sameposition and orientation as the viewing camera, as longas only valid rays are created. However, when the view-ing camera parameters change in a way that invalid raysare created, we restrict the view direction of the samplingcamera, and thus, ensure that all rays intersect the terrainbase-plane (see Fig. 4b). It is important to emphasize thatin our solution the terrain is sampled with respect to thesampling camera and rendered using the viewing camera.

The offset problem disappears when the visible regionof the terrain is entirely included within the sampled re-gion (of the sampling camera). This is true for FOV angleabove 90◦, since the sampling camera starts sampling datajust below the viewpoint and ends at the far horizon.For FOV angle below 90◦, we can extend the lower part

Fig. 4a,b. Camera restriction. a A peak missed by the viewing cam-era (in red). b The use of a sampling camera

A GPU persistent grid mapping for terrain rendering 143

of the sampling camera’s viewport such that the first (thelowest) ray is vertical. This simple solution has a seriousdrawback since the extension can reach the size of the ori-ginal viewport. However, usually such extension is morethan is necessary and wastes samples on invisible terrainregions that lie below the camera.

The required extension of the viewport can be in-teractively calculated with a minor computational effort.The extension depends on the maximal terrain height onthe missed area (unsampled area below the camera). Themaximal terrain height can be easily estimated by usingmultiple-level hierarchy which maintains maximal heightsof the terrain at different resolutions (the constructionof a similar hierarchy is described in detail in Sect. 3.4).Equation 3 calculates the extension angle γ of the lowerpart of the viewport, where h is the height of the cam-era from the terrain base-plane, m is the maximal terrainheight from the base-plane on the missed region, and r isthe distance on the base-plane between the viewpoint andits nearest ray-base-plane intersection as shown in Fig. 5:

tan α = r

h,

tan β = r − rmh

h= r(h −m)

h2 ,

tan γ = tan α− tan β

1+ tan α tan β= rhm

h3 +r2(h −m). (3)

There are two options to extend the persistent grid tocover the expanded viewport. The first is to add trian-gle strips, where the size and the number of strips aredetermined by the persistent grid’s density. This solutionensures the absence of cracks since the boundary verticesof the persistent grid and strips go through the same calcu-lations. The second option is to stretch the persistent gridto cover the additional area of the viewport.

Fig. 5. The viewport extension angle γ . The original view frus-tum, and its extension, are shown by dark and light gray colors,respectively

Figure 6 shows a close peak rendered using a samplingcamera. The view frustums of the viewing camera andsampling camera are colored in green and white, respec-tively. Note that the sampling camera retains the samplingdensity of the viewing camera for regions shared by thetwo cameras.

3.3 View-dependent rendering

View-dependent rendering algorithms try to represent ob-jects with respect to their visual importance in the finalimage. Traditional approaches for terrain rendering usu-ally rely on off-line-constructed hierarchies of levels ofdetail. Then, at runtime approximated screen-space pro-jection error is used to guide the selection of various reso-lutions over different regions in object space [3, 19, 31].

In contrast, PGM does not require such intensive pre-processing to construct multiresolution hierarchies. The

Fig. 6a,b. A close peak. a Side view of the viewing (green) andsampling (white) cameras. b The resulting image

144 Y. Livny et al.

Fig. 7. Smooth transition between adjacent levels of detail (side-view of a mapped persistent grid of size 20×20 samples)

perspective mapping of the persistent grid onto the terraingenerates different levels of detail in an automatic man-ner. Similar triangles on the persistent grid are mappedto different-size triangles on the terrain – close-to-viewertriangles occupy smaller regions than far-from-viewer tri-angles. In such an approach, the terrain regions are inher-ently represented according to their visual importance inthe final image, and the transition between adjacent levelsof detail is smooth as shown in Fig. 7.

Reducing the number of polygons sent to the graph-ics hardware by culling invisible geometry has been usedto accelerate the rendering of large virtual scenes. View-frustum culling, back-face culling, and occlusion cullingare used to achieve this goal. In contrast, our approachdoes not need to explicitly apply any culling algorithmsince the mapped persistent grid delimits and usually re-sembles the view frustum.

3.4 Terrain sampling

The mapping procedure displaces the persistent grid ac-cording to the visible region of the terrain. However, thisprocedure often fails to generate a faithful image of theterrain as a result of using sparse sampling with narrowfilters (the value of the nearest pixel or an interpolationof the adjacent four pixels). Figure 8 shows an exampleof missing vital details of the rendered terrain. Practically,this is a sampling problem, and according to Shannon’stheorem [38] for faithful sampling of an input function f ,one needs to sample with more than twice the frequencyof the highest-frequency component of f . In our algo-rithm, the sampling is dictated by the resolution of thepersistent grid and the distance from the viewpoint. Al-though we have little control over the sampling resolution,we can reduce the frequency of the function, i.e., the ter-rain, by applying a low-pass filter. A low-pass filter couldbe performed on the image space by replacing a pixelby the weighted average of its neighborhood. The influ-ence of the low-pass filter, i.e., the neighborhood’s size,varies with respect to the distance from viewpoint. Since

Fig. 8. Missing details (hill and lake) of the rendered terrain

each filter execution requires fetching the neighborhoodpixels from video memory, which is a fairly slow opera-tion even in the newest graphics hardware, we approxi-mate these filters and store them in multiple-level texturepyramids.

In our scheme, we use multiple-level texture pyramidsat successive powers of two to cache elevation and colormaps. Since these pyramids are similar to mipmaps, wecould let the hardware construct them and then, at the ver-tex processor, our algorithm would determine from whichlevel to select the values. However, such an approach doesnot work when the terrain size exceeds the capacity of thebase level of the mipmaps. In Sect. 4 we introduce our ex-ternal texture memory scheme that handles large terrains.

The multiple-level texture pyramids are constructedonce in real-time by the CPU before being transmitted tothe texture memory. Starting with the original (most de-tailed) level, each level is generated from the previous oneby reducing the resolution by half at each dimension. Thepixels in the generated level are computed by averagingthe four corresponding pixels of the previous level (to ap-proximate a low-pass filter with a neighborhood of sizefour, where pixels are equidistant from the center of thefilter).

The mapping procedure fetches the height and colorvalues from the pyramids’ texture level of resolution thatfits the geometric level of detail (the sampling density)at the mapped vertex vi . Therefore, the selection of tex-ture level is guided by the distance ri between the ver-tex vi and its farthest adjacent neighbor on the base-plane(see Fig. 9a). It is easy to determine the adjacent neigh-bors of a vertex since the mapping of the persistent gridpreserves connectivity. One way to compute ri is by cal-culating the distance between two corresponding adjacentray-base-plane intersection points. Equation 4 shows analternative computation of ri based on the height h of theviewpoint from the terrain base-plane, the distance di be-tween the viewpoint and the vertex vi , the distance qi ,which is the projection of di onto the base-plane, and αithe angle between the rays to vi and to its farthest adjacentneighbor as shown in Fig. 9. To simplify the enumerationof the vertices (the index i), let us consider the 2D case.The vertex, which ray is perpendicular to the viewport, is

A GPU persistent grid mapping for terrain rendering 145

Fig. 9a,b. Computing the level of detail at vertex vi . a The dis-tance ri between vi and its farthest adjacent neighbor. b Theangle αi between the rays to vi and its farthest adjacent neighbor

assigned the index 0, and vertices above and below it areconsecutively enumerated from 1 to n, and from −1 to −n,respectively:

ri = d2i sin αi

h cosαi −qi sin αi= d2

i tan αi

h −qi tan αi. (4)

Equation 5 computes the angle αi between the ray tovi and its farthest adjacent ray, where ∆ is the distancebetween the two adjacent samples on the viewport. Notethat we assume a uniform persistent grid, and hence, ∆ isfixed. To simplify the presentation, Eq. 5 considers non-negative indexes only (the equation for negative indexescan also be achieved in a similar way):

tan(Ai) = i∆,

tan(Bi) = (i +1)∆,

tan(αi) = tan(Bi − Ai) = tan(Bi)− tan(Ai)

1+ tan(Bi) tan(Ai)

= ∆(i +1)−∆i

1+ i∆(i +1)∆= ∆

1+ i(i +1)∆2 . (5)

Based on the distance ri , Eq. 6 computes a level ofdetail (lod) at vertex vi . As we mentioned earlier, lod cor-responds to the texture level in pyramids, which is used toselect the height and color values for vi :

lod = max(0, �log(ri)�) (6)

3.5 Temporal interpolation

The persistent grid mapping cannot maintain temporalcontinuity for both geometry and color for far-from-viewer regions as a result of sampling from coarse levelsof elevation and color maps. This may lead to popping ef-fects that appear when samples of the same region moveslightly over consecutive frames and fall at adjacent pix-els. Such popping effects are even more evident whenthe adjacent pixels belong to different texture levels. Toprevent such a drawback, we linearly interpolate the fouradjacent pixels and the parent pixel (from the coarser tex-ture level) of the sampling point s. Since these adjacentpixels may have different parents, we first interpolate fouradjacent pixels from the coarser level and refer to the re-

Fig. 10. The graph of the parent pixel’s contribution for the fivefinest levels of detail

Fig. 11a,b. A terrain rendered with (a) and without (b) interpola-tions

146 Y. Livny et al.

sulting value as the parent pixel. The weight of each pixeldepends on its distance from s, and the contribution of theparent pixel depends on how close we are to switching tothe next level. To determine the weight of the parent, wecan use any continuously increasing function that returnsvalues from 0 (when just switching to a new level) until 1(when reaching the next level). Equation 7 calculates theweight of the parent Wp by using a linear function, andFig. 10 presents the corresponding graph for the five finestlevels of detail. In Eq. 7, dist(V, s) is the distance of thesampling point s from the projected viewpoint V , lod isthe level of detail at s, and range(lod) is the range of thelevel of detail on the terrain base-plane. The range of themost detailed level (index 0) is 1 and the range of eachnext level of detail is twice the previous one. Figure 11shows a terrain rendered with and without height and colorinterpolations:

Wp = dist(V, s)− range(lod−1)

range(lod)− range(lod−1)

= dist(V, s)

range(lod−1)−1 = dist(V, s)

2lod−1 −1. (7)

4 External texture memory support

So far our algorithm has assumed that the elevation andcolor maps fit in texture memory. However, current terraindatasets often exceed the capacity of typical texture mem-ory. Handling large datasets usually includes two upload-ing stages – from external media into main memory andfrom main memory into texture memory. Uploading datafrom external media into main memory has been widelystudied [21, 28], and it is outside the scope of this paper. Incurrent hardware, the limited size of texture memory callsfor designing schemes to efficiently load data from mainmemory into texture memory.

Our external texture memory manager builds multiple-level pyramids once, on the fly, and maintains in texturememory the portions of data necessary for rendering the

Fig. 12a,b. The clipmaps tiles. a Nested clipmaps centered aboutthe viewpoint. b The persistent grid is mapped across severalclipmaps

next frame. The upload from main memory into texturememory is performed by fetching nested clipmaps cen-tered at the viewpoint [1, 40], as shown in Fig. 12. Eventhough these clipmap levels occupy the same memorysize, they cover increasing regions of the terrain. Eachextracted level is an independent texture that requires sep-arate binding (performed by the CPU) when it is used bya mapped vertex. However, the CPU cannot predict thelevel of detail of the mapped vertices since the selection oflevel of detail is determined at the vertex processor.

One could resolve this limitation by binding severaltextures and selecting the appropriate texture map in real-time at the vertex processor. However, the number of tex-tures that can be bound at the same time is limited andvaries for different graphics cards. Moreover, the selectionof the appropriate texture map involves branching opera-tions which are expensive in current GPUs. Therefore, weapply a technique that uses multiple-texture maps withoutrebinding or branching. We achieve this by laying all thedifferent texture levels into one large texture similar to theidea of texture atlases [33]. The texture levels tile up uni-formly because of their equal sizes, as shown in Fig. 13.

Fig. 13a,b. The layout of different texture levels into one texturemap. a The texture pyramid stores the entire terrain in decreasingresolutions. b Clipmaps are laid on the texture atlas

Fig. 14. Cg function that converts vertex coordinates into textureatlas coordinates

A GPU persistent grid mapping for terrain rendering 147

Fig. 15a,b. Fragment processing. a Incorrect pixels resulting fromautomatic interpolation on the fragment processor. b Correct imagegenerated by explicitly calculating the texture coordinates

In such a scheme, the level of detail of a vertex determinesthe appropriate tile and the texture coordinates are cal-culated accordingly. Figure 14 shows the Cg code of thefunction that receives the coordinates and level of detail ofa vertex, and computes its texture coordinates.

In traditional texture atlases, triangle texture coordi-nates do not span different sub-tiles of the atlas. How-ever, in our algorithm adjacent vertices may fall in twoconsecutive levels of detail. In such a case, the generatedfragments fall across different tiles resulting in incorrectpixels (see Fig. 15a). Such incorrectness occurs due to theautomatic interpolation done on the fragment processor.To resolve this problem, the fragment processor explicitlycalculates the correct texture coordinates for each frag-ment based on parameters provided by the vertex proces-sor (see Fig. 15b).

Fig. 16a,b. The modification (blue color) in the clipmaps result-ing from a camera movement. a Clipmap layout. b F-shape textureatlas

The changes in view parameters modify the viewed re-gion, usually in a continuous manner. To avoid expensivemodification of the entire texture memory and to utilizetemporal coherence, each tile undergoes an L-shape mod-ification similar to [1]. Since the resolution of clipmaplevels decreases exponentially, the area that needs to beupdated becomes smaller (coarse levels are seldom up-dated). In general, the updated areas of all the tiles that layin one texture, form an F-shape (see Fig. 16).

5 Implementation details

We have implemented our algorithm in C++ and Cg forMicrosoft. Then, we have tested it on various datasets andreceived encouraging results.

If we assume that the terrain dataset entirely fits in tex-ture memory, then the implementation of our algorithmis simple. The persistent grid is generated and stored invideo memory, and the mapping procedure is performedby several Cg instructions within the GPU. In such a case,the naive hardware-generated mipmaps can be used as thetexture pyramids. The need for external texture memorysupport requires the construction of the clipmap pyramidswhich is performed by the CPU. Then at runtime, theappropriate portions of these pyramids are transferred totexture memory. The update of the clipmaps is performedin an active manner by transferring several rows/columnsin each frame.

To determine the (interpolated) height of a vertex, weneed the elevation data of the four adjacent pixels fromthe appropriate texture level, and the four adjacent pixelsfrom the coarser level (for the parent pixel). This implieseight fetches per vertex, which are extremely expensiveoperations. Since four floats can be fetched by a singleoperation, careful layout of the data in texture memory en-ables significant reduction in the number of fetches. Thedepth of the elevation data is 16 bits, therefore, all thedata needed for a vertex can be stored in four consecutive32-bit floats and fetched by a single operation. This lay-out indicates that each pixel is stored eight times in the

148 Y. Livny et al.

texture memory. However, since we use texture pyramids,such redundant use of the texture memory is not critical.Similarly, for each fragment, we perform two fetches tointerpolate 32-bit colors. To perform a single fetch, wecan reduce the color quality to 16-bits, or alternatively,use partial interpolation by ignoring the parent contribu-tion. Note that using a small number of fetches per frag-ment compromises image quality for frame rates and viceversa.

6 Experimental results

The results we report in this section have been achievedon a PC with an AMD Athlon 3500+ processor, 1 GBof memory, and an NVIDIA GeForce 7800 GTX graph-ics card with 256 MB texture memory. We have used16K×16K pixels from Puget Sound and 4K×2K pixelsfrom Grand Canyon as our main datasets.

Table 1 summarizes the performance of our algorithmand its external texture memory scheme. The first andsecond columns show the resolution and triangle countof persistent grids of different sizes (we tested square,as well as rectangular persistent grids). The remainingcolumns show the resulting frame rates under various set-tings. The third and fourth columns report the frame rateswhen performing one and two fetches per fragment, re-spectively. The column Multiple textures shows the framerates achieved by using multiple binding (with branching)for the different texture levels. The difference between thiscolumn and the preceding two columns demonstrates theessentialness of our scheme to encode different level-of-detail maps into one texture. Notice that the used datasetis irrelevant for measuring the frame rates, since the timecomplexity of PGM is determined by the size of the per-sistent grid.

The processing times for the various steps of the ren-dering process for the vertex and fragment processors arepresented in Table 2. These times have been measuredover a single frame using a persistent grid of size 450 ×450, while performing two fetches in the fragment proces-sor. Based on the overall processing time, we can conclude

Table 1. The performance of the PGM algorithm for various persis-tent grid sizes and fetch counts

Persistent Triangle Frames/secondgrid size number 1 Fragment 2 Fragment Multiple

(K) fetch fetches textures

150×600 180 226 177 83200×800 320 133 119 56430×430 370 120 112 54300×900 540 81 78 37600×600 720 59 59 25400×1600 1280 35 35 16

Table 2. Processing times for the various steps of the rendering (inmilliseconds)

Component Vertex processor Fragment processorms % ms %

Computations 2.56 37 0.16 6Fetches 2.30 33 0.66 21Interpolations 2.05 30 3.16 73

Overall 6.91 100 3.98 100

Table 3. The extension (percent) of the viewport required to solvethe offset problem

View angle Maximal terrain height/Camera height1.0 0.8 0.5 0.2

< 30◦ 37 28 16 840◦ 20 16 9 445◦ 15 10 7 350◦ 10 8 5 2

≥ 60◦ 0 0 0 0

that the performance of our algorithm is bounded by thevertex processor’s computation power.

As we have described in Sect. 3.2, the offset problemcan be solved by extending the lower part of the samplingcamera’s viewport. In Table 3, we present the average ex-tension of the viewport required for different flyovers ofa terrain using FOV angle of 60◦. The column View angleincludes different view angles of the viewing camera. Thesecond column through the fifth column report the aver-age required extension (in percentage) of the viewport forvarious ratios between the camera height, from the base-plane, and the maximal terrain height in the missed area,which are represented by h and m in Fig. 5, respectively.Note that for the view angle of 60◦ and above, there isno need to extend the viewport, since the terrain is sam-pled just below the camera and offset problem does notoccur.

6.1 Error metrics

We use two error metrics to evaluate the quality of the cre-ated image – persistent-grid distortion value metric andthe traditional screen-space error metric. The persistent-grid distortion value is defined as the Hausdorff distancebetween a uniform persistent grid, used for ray shooting,and the reprojection of the generated mesh onto the view-port. Table 4 reports distortion value result from render-ing the Puget Sound terrain, while using 640 ×480 and1024 ×768 window resolutions and different-size persis-tent grids. A zero distortion implies that the persistent gridremains uniform after mesh sampling and reprojectiononto the viewport. However, such a case does not occuroften due to vertex displacement (depends on the terrain

A GPU persistent grid mapping for terrain rendering 149

Table 4. Persistent-grid distortion value

Persistent Hausdorff distance (pixels)grid size 640×480 Window 1024×768 Window

150×600 3.9 6.2200×800 3.8 6.0430×430 1.9 3.0300×900 2.2 3.5600×600 1.2 2.0400×1600 1.0 1.6

height) and forces the persistent grid to slightly lose itsaccuracy (see Fig. 17).

The second metric measures the screen-space error byprojecting the height difference between an original ver-tex and its corresponding sampled vertex onto the screen.Table 5 presents the screen-space error values of vari-ous virtual flights (gaze directions) over the Puget Sounddataset using different-size persistent grids and two win-dow resolutions. The second column through the fifth col-umn show the maximum and average errors using a win-dow of resolution 640 ×480; and the sixth through theninth columns show equivalent results using a window

Fig. 17. The distortion of the persistent grid (of size 50×50)

Table 5. Screen-space error for the Puget Sound dataset

Persistent 640×480 Window resolution 1024×768 Window resolutiongrid size Max error Avg error Max error Avg error

Pixels % Pixels % Pixels % Pixels %

150×600 6.0 1.25 2.3 0.48 9.1 1.18 3.4 0.44200×800 5.3 1.10 2.1 0.44 8.1 1.05 3.0 0.39430×430 5.9 1.23 2.2 0.46 9.0 1.17 3.4 0.44300×900 4.2 0.88 1.0 0.21 6.2 0.81 1.5 0.20600×600 4.9 1.02 1.6 0.33 7.0 0.91 2.3 0.30400×1600 3.4 0.71 0.3 0.06 5.3 0.69 0.5 0.07

resolution 1024 × 768. The maximal and average errorpercentage (Max error % and Avg error %) columns re-port the screen-space error of the sampled vertices withrespect to the window size. As can be seen, the increase inthe number of samples, as expected, leads to better imagequality. Moreover, our experiments show that rectangu-lar grids result in smaller error bounds than square grids,since rectangular grids better match the view-frustumshape. For instance, a 200 × 800 grid imposes smallererror than a 430×430 grid, even though the first grid hasfewer samples.

We have used a persistent grid of size 200 ×800 pro-jected on a 640 ×480 window for further analysis of thebehavior of the screen-space error and its dependency onthe camera’s view direction. Table 6 shows the maximalscreen-space error values measured for various view an-gles of the camera. For each view angle, we report sep-arately the results of different flying paths (1000 frames-length) over flat and mountainous areas of the PugetSound dataset. As expected, the screen-space error at flatregions is smaller than that at mountainous regions. More-over, the screen-space error increases as the view angledecreases, since far from camera triangles become largeand result in sparse inaccurate sampling of the terrain.

6.2 External texture memory

Table 7 summarizes the performance of our external tex-ture memory scheme with respect to various tile sizesand three navigation patterns: fast, medium, and slow mo-tion. The Entire texture column reports the time, in mil-liseconds, of updating the entire texture in each frame.Such a scenario results in unacceptable frame rates. TheF-shape update columns report texture updating time fordifferent navigation patterns. The reported times verifythat the fast-motion navigation implies intensive update oftiles, whereas the slow-motion navigation requires slightupdate of textures in each frame.

6.3 Discussion and comparisons

As can be seen, PGM manages to achieve high frame rateswhile generating quality images. Figures 18 and 19 show

150 Y. Livny et al.

Table 6. Maximal screen-space error (pixels) according to the cam-era’s view angle

View angle Terrain regionFlat Mountainous

90◦ 0.1 0.280◦ 0.5 1.170◦ 0.6 1.860◦ 1.0 2.750◦ 1.3 3.440◦ 1.6 4.130◦ 1.8 4.520◦ 1.9 4.910◦ 2.1 5.2

0◦ 2.1 5.3

Table 7. The performance of external texture memory scheme

Tile size Entire texture F-shape update (ms)(pixels) (ms) Fast Medium Slow

1282 38 1.22 0.17 0.012562 161 1.57 0.63 0.015122 994 3.59 1.39 0.02

two snapshots of the Puget Sound and the Grand Canyondatasets, respectively, using a uniform persistent grid ofsize 200 ×800. Our algorithm is designed to intensivelyutilize advanced features of modern GPU and thus pro-vides a number of notable advantages over previous ter-rain rendering schemes. Since most of the computationsare done on the GPU, the frequently overloaded CPU be-comes free for other tasks. Moreover, as a result of usingthe same cached geometry for each frame, only the datarequired for updating the texture pyramids are transformedfrom the CPU to the graphics hardware. However, these

Fig. 18. A snapshot from the Puget Sound dataset generated by thePGM algorithm

data are very compact (contain only the height compon-ent), and thus do not overload the communication channelbetween the CPU and graphics hardware.

Our algorithm suffers a loose control over screen-spaceerror as a result of using perspective mapping of the per-sistent grid to guide the selection of level-of-detail overthe terrain surface. Such an approach could generate largetriangles at the far horizon. However, these faraway trian-gles are usually projected into very small areas of the finalimage. In addition, our algorithm does not take into ac-count surface curvature – it samples flat and mountainousregions, at the same distance from viewpoint, by the sameresolution.

Using separate cameras for sampling and rendering theterrain may waste computational power if geometry gener-ated by the sampling camera is culled by a view-frustumof the viewing camera. The amount of culled samplesdepends on view angle and height of the camera. Our ex-periments have shown that for typical view parameters,such as FOV angle of 60◦ and horizontal view direction,the amount of culled samples (geometry) is not high. Forexample, a flyover of a terrain at altitude around four timesthe height of the terrain, from the base-plane, results inculling around 25% of the sampled geometry, and almostno culling when flying at an altitude less than twice theheight of the terrain.

As we mentioned in Sect. 3, the distribution of the gridvertices is not constrained – a grid can be uniform or irreg-ular. Figure 20 shows an example of a focus-guided visu-alization of terrain achieved by using a spherical persistentgrid with parameterized subdivision. It is also possible todynamically resize the persistent grid in order to increasethe resolution at the terrain’s visible region and reduce thenumber of wasted samples. For example, when the sky oc-cupies a large fraction of the final image, it is possible to

Fig. 19. An image of the Grand Canyon rendered by PGM

A GPU persistent grid mapping for terrain rendering 151

Fig. 20a,b. A spherical persistent grid with parameterized subdivi-sion. a Shaded surface. b Wireframe

shrink the persistent grid according to the visible region ofterrain.

The most related approach to this work is geometryclipmaps, since both utilize the GPU to accelerate therendering of large terrains. Asirvatham and Hoppe [1] re-port a frame rate of 87 fps when rendering approximately1.1 M∆/frame on NVIDIA GeForce 6800 GT. Afterview-frustum culling the number of rendered triangles isreduced to about 370 K∆/frame which is equivalent to ourpersistent grid of size 430×430. Using current compara-ble graphics hardware (a GeForce 7800 GTX card), theywould obtain approximately 43.1 M∆/s, which is similarto the 44.4 M∆/s achieved by PGM using a persistent gridof size 430×430 with a single fragment fetch and interpo-lations. Both, the geometry clipmaps and PGM algorithm,reach similar error tolerance, however, as a result of using

a continuous mesh, we achieve a smooth terrain surfacewithout cracks or degenerate triangles. The clipmaps algo-rithm has better control over the size of sampled triangles,although our algorithm achieves steadier frame rates byselecting a persistent grid that matches the rendering ca-pabilities of the graphics hardware.

A similar comparison can be made with other relatedworks. Hwa et al. [21] render 42.6 M∆/s after using view-frustum culling, whereas Cignoni et al. [5] achieve about46.7 M∆/s. All these approaches select levels of detailbased on surface features and thus, obviously, achievehigher image quality than the PGM algorithm. However,they are required to construct view-dependent hierarchiesin a preprocessing stage and then, to maintain and updatethe triangulated surface at runtime.

A video segment in QuickTime MPEG4 format (371_2007_180_MOESM1_ESM.mp4) that demonstrates theperformance of the PGM algorithm accompanies thispaper.

7 Conclusions and future work

We have presented a novel framework for rendering largeterrain datasets at interactive rates by utilizing advancedfeatures of current graphics hardware. The sampling of theterrain is performed by fast ray shooting within the GPU.The use of a mesh, as the final rendering representationof the viewed surface, eliminates cracks and allows theuse of typical illumination models. Since the complexityof the rendering mesh is constant (as a result of using thesame persistent grid), the rendering frame rates are smoothand steady. The view-dependent level-of-detail renderingis performed in an automatic fashion by the perspectivemapping of the persistent grid onto the terrain. In addition,our external texture memory scheme allows the renderingof large terrain datasets in an efficient manner. It avoidsrebinding of textures by embedding all the levels of de-tail in the same texture, which is updated by using F-shapemodifications.

We expect that the current trend in improving the ver-tex processor will continue and directly contribute to theperformance of the PGM algorithm. We see the scope offuture work in improving the metrics used in the construc-tion of the multiple-level texture pyramids. An interestingfuture direction would be to adjust the persistent grid toa screen-space error, and thus, reduce and bound the errortolerance. It is important to study the feasibility of usingPGM for image-based and general-models rendering.

Acknowledgement This work is supported by the Lynn andWilliam Frankel Center for Computer Sciences and the Israel Min-istry of Science and Technology. In addition, we would like tothank Mr. Yoel Shoshan for his assistance with the implementa-tion.

152 Y. Livny et al.

References

1. Asirvatham, A., Hoppe, H.: Terrainrendering using GPU-based geometryclipmaps. GPU Gems 2, 27–45 (2005)

2. Bao, X., Pajarola, R., Shafae, M.: SMART:an efficient technique for massive terrainvisualization from out-of-core. In:Proceedings of Vision, Modeling andVisualization ’04, pp. 413–420 (2004)

3. Blow, J.: Terrain rendering at high levels ofdetail. In: Game Developers Conference(2000)

4. Bolz, J., Schröder, P.: Evaluation ofsubdivision surfaces on programmablegraphics hardware (2005)

5. Cignoni, P., Ganovelli, F., Gobbetti, E.,Marton, F., Ponchio, F., Scopigno, R.:BDAM – batched dynamic adaptive meshesfor high performance terrain visualization.Comput. Graph. Forum 22(3), 505–514(2003)

6. Cignoni, P., Ganovelli, F., Gobbetti, E.,Marton, F., Ponchio, F., Scopigno, R.:Planet-sized batched dynamic adaptivemeshes (P-BDAM). In: Proceedings ofVisualization ’03, pp. 147–155 (2003)

7. Cignoni, P., Ganovelli, F., Gobbetti, E.,Marton, F., Ponchio, F., Scopigno, R.:Adaptive tetrapuzzles: efficient out-of-coreconstruction and visualization of giganticmultiresolution polygonal models. ACMTrans. Graph. 23(3), 796–803 (2004)(DOI: 10.1145/1015706.1015802)

8. Cohen-Or, D., Levanoni, Y.: Temporalcontinuity of levels of detail in Delaunaytriangulated terrain. In: Proceedings ofVisualization ’96, pp. 37–42 (1996)

9. Dachsbacher, C., Stamminger, M.:Rendering procedural terrain by geometryimage warping. In: Processing ofEurographics Symposium in Geometry,pp. 138–145 (2004)

10. De Floriani, L., Magillo, P., Puppo, E.:Building and traversing a surface atvariable resolution. In: Proceedings ofVisualization ’97, pp. 103–110 (1997)

11. Doggett, M., Hirche, J.: Adaptive viewdependent tessellation of displacementmaps. In: HWWS ’00: Proceedings of theACM SIGGRAPH/EUROGRAPHICSWorkshop on Graphics Hardware,pp. 59–66 (2000) (DOI:10.1145/346876.348220)

12. Döllner, J., Baumann, K., Hinrichs, K.:Texturing techniques for terrainvisualization. In: Proceedings ofVisualization ’00, pp. 227–234 (2000)

13. Duchaineau, M., Wolinsky, M., Sigeti, D.,Miller, M., Aldrich, C.,Mineev-Weinstein, M.: ROAMing terrain:real-time optimally adapting meshes.

In: Proceedings of Visualization ’97,pp. 81–88 (1997)

14. El-Sana, J., Varshney, A.: Generalizedview-dependent simplification. Comput.Graph. Forum 18(3), 83–94 (1999)

15. Evans, W.S., Kirkpatrick, D.G., Townsend,G.: Right-triangulated irregular networks.Algorithmica 30(2), 264–286 (2001)

16. Gerasimov, G., Fernando, F., Green, S.:Shader model 3.0 using vertex textures.White Paper (2004)

17. Gumhold, S., Hüttner, T.: Multiresolutionrendering with displacement mapping. In:HWWS ’99: Proceedings of the ACMSIGGRAPH/EUROGRAPHICS Workshopon Graphics Hardware, pp. 55–66 (1999)(DOI: 10.1145/311534.311578)

18. Hitchner, L., McGreevy, M.: Methods foruser-based reduction of model complexityfor virtual planetary exploration. In:Proceedings of SPIE ’93, pp. 622–636(1993)

19. Hoppe, H.: Smooth view-dependentlevel-of-detail control and its application toterrain rendering. In: Proceedings ofVisualization ’98, pp. 35–42 (1998)

20. Hoppe, H.: Optimization of mesh localityfor transparent vertex caching. In:Proceedings of SIGGRAPH ’99,pp. 269–276 (1999)

21. Hwa, L.M., Duchaineau, M.A., Joy, K.I.:Adaptive 4-8 texture hierarchies. In:Proceedings of Visualization ’04,pp. 219–226 (2004)

22. Johanson, C.: Real-time water rendering –introducing the projected grid concept.Dissertation, Lund University (2004)

23. Kryachko, Y.: Using vertex texturedisplacement for realistic water rendering.GPU Gems 2, 283–294 (2005)

24. Lario, R., Pajarola, R., Tirado, F.:HyperBlock-QuadTIN: hyper-blockquadtree based triangulated irregularnetworks. In: Proceedings of IASTEDVIIP, pp. 733–738 (2003)

25. Larsen, B.S., Christensen, N.J.: Real-timeterrain rendering using smooth hardwareoptimized level of detail. In: WSCG (2003)

26. Levenberg, J.: Fast view-dependentlevel-of-detail rendering using cachedgeometry. In: Proceedings ofVisualization ’02, pp. 259–266 (2002)

27. Lindstrom, P., Koller, D., Ribarsky, W.,Hodges, L.F., Faust, N., Turner, G.A.:Real-time, continuous level of detailrendering of height fields. In: Proceedingsof SIGGRAPH ’96, pp. 109–118 (1996)

28. Lindstrom, P., Pascucci, V.: Terrainsimplification simplified: A generalframework for view-dependent out-of-core

visualization. IEEE Trans. Vis. Comput.Graph. 8(3), 239–254 (2002) (DOI:10.1109/TVCG.2002.1021577)

29. Losasso, F., Hoppe, H.: Geometryclipmaps: terrain rendering using nestedregular grids. ACM Trans. Graph. 23(3),769–776 (2004) (DOI: 10.1145/

1015706.1015799)30. Losasso, F., Hoppe, H., Schaefer, S.,

Warren, J.: Smooth geometry images. In:Processing of Eurographics Symposium inGeometry Processing, pp. 138–145 (2003)

31. Luebke, D., Erikson, C.: View-dependentsimplification of arbitrary polygonalenvironments. In: Proceedings ofSIGGRAPH ’97, pp. 198–208 (1997)

32. Moule, K., McCool, M.D.: Efficientbounded adaptive tessellation ofdisplacement maps. In: Proceedings ofGraphics Interface, pp. 171–180 (2002)

33. NVIDIA: Improve batching using textureatlases. SDK White Paper (2004)

34. Pajarola, R.: Large scale terrainvisualization using the restricted quadtreetriangulation. In: Proceedings ofVisualization ’98, pp. 19–26 (1998)

35. Pomeranz, A.: ROAM using triangleclusters (RUSTiC). Dissertation, Universityof California at Davis (2000)

36. Rabinovich, B., Gotsman, C.: Visualizationof large terrains in resource-limitedcomputing environments. In: Proceedingsof Visualization ’97, pp. 95–102 (1997)

37. Schneider, J., Westermann, R.:GPU-friendly high-quality terrainrendering. WSCG 14(1–3), 49–56 (2006)

38. Shannon, C.E.: A mathematical theory ofcommunication. Bell Syst. Tech. J. 27,379–423 (1948)

39. Southern, R., Gain, J.: Creation and controlof real-time continuous level of detail onprogrammable graphics hardware. Comput.Graph. Forum 22(1), 35–48 (2003)

40. Tanner, C.C., Migdal, C.J., Jones, M.T.:The clipmap: a virtual mipmap. In:Proceedings of SIGGRAPH ’98,pp. 151–158 (1998) (DOI: 10.1145/

280814.280855)41. Ulrich, T.: Rendering massive terrains

using chunked level of detail control. In:Proceedings of SIGGRAPH ’02 (2002)

42. Wagner, D.: Terrain geomorphing in thevertex shader. ShaderX2: ShaderProgramming Tips & Tricks with DirectX 9(2004)

43. Yoon, S.E., Salomon, B., Gayle, R.:Quick-VDR: Out-of-core view-dependentrendering of gigantic models. IEEE Trans.Vis. Comput. Graph. 11(4), 369–382(2005) (DOI: 10.1109/TVCG.2005.64)

A GPU persistent grid mapping for terrain rendering 153

YOTAM LIVNY is a Ph.D. student of ComputerScience at the Ben-Gurion University of theNegev, Israel. His research interest includes in-teractive rendering of 3D graphic models usingacceleration tools, such as view-dependent ren-dering and dynamic data organization for op-timal graphics hardware usage. Yotam receiveda B.Sc. in Mathematics and Computer Sciencefrom the Ben-Gurion University of the Negev,Israel in 2003. He is currently persuing a Ph.D.in Computer Science under the advisory of Dr.Jihad El-Sana.

NETA SOKOLOVSKY is a Ph.D. student of Com-puter Science at Ben-Gurion University of theNegev, Israel. Her research interests include 3Dinteractive graphics, occlusion culling, view-dependent rendering, image processing, andvideo visualization. Neta received a B.Sc. andM.Sc. in Computer Science from Ben-Gurion

University of the Negev, Israel in 1999 and2001, respectively. She is persuing a Ph.D. inComputer Science under Dr. Jihad El-Sana.

TAL GRINSHPOUN is a Ph.D. student of Com-puter Science at Ben-Gurion University of theNegev, Israel. His research interests includecomputer graphics, distributed security, and dis-tributed search. Tal received a B.Sc. in Mathe-matics and Computer Science from Ben-GurionUniversity of the Negev, Israel in 1998. He re-ceived a M.Sc. in Computer Science from Ben-Gurion University of the Negev, Israel in 2005under the advisory of Dr. Jihad El-Sana. Tal iscurrently studying for a Ph.D. in Computer Sci-ence under the advisory of Prof. Amnon Meisels.

JIHAD EL-SANA is a Senior Lecturer of Com-puter Science at Ben-Gurion University of theNegev, Israel. El-Sana’s research interests in-

clude 3D interactive graphics, multiresolutionhierarchies, geometric modeling, computationalgeometry, virtual environments, and distributedand scientific visualization. His research focuseson polygonal simplification, occlusion culling,accelerating rendering, remote/distributed vi-sualization, and exploring the applications ofvirtual reality in engineering, science, andmedicine. El-Sana received a B.Sc. and M.Sc.in Computer Science from Ben-Gurion Univer-sity of the Negev, Israel in 1991 and 1993. Hereceived a Ph.D. in Computer Science from theState University of New York at Stony Brookin 1999. El-Sana has published over 20 papersin international conferences and journals. He isa member of the ACM, Eurographics, and IEEE.