Thesis no: MECS-2014-08

Tile Based Procedural Terrain

Generation in Real-Time

A Study in Performance

David Grelsson

Faculty of Computing

Blekinge Institute of Technology

SE�371 79 Karlskrona, Sweden

This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology

in partial ful�llment of the requirements for the degree of Master of Science in Engineering:

Game and Software Engineering. The thesis is equivalent to 20 weeks of full time studies.

Contact Information:

Author(s):David GrelssonE-mail: dagc09@student.bth.se

University advisor:Prof. Johan HagelbäckSchool of Computing

Faculty of Computing Internet : www.bth.seBlekinge Institute of Technology Phone : +46 455 38 50 00SE�371 79 Karlskrona, Sweden Fax : +46 455 38 50 57

Abstract

Context. Procedural Terrain Generation refers to the algorithmicalcreation of terrains with limited or no user input. Terrains are animportant piece of content in many video games and other forms ofsimulations.Objectives. In this study a tile-based approach to creating endlessterrains is investigated. The aim is to �nd if real-time performanceis possible using the proposed method and possible performance in-creases from utilization of the GPU.Methods. An application that allows the user to walk around on aseemingly endless terrain is created in two versions, one that exclu-sively utilizes the CPU and one that utilizes both CPU and GPU.An experiment is then conducted that measures performance of bothversions of the application.Results. Results showed that real-time performance is indeed pos-sible for smaller tile sizes on the CPU. They also showed that theapplication bene�ts signi�cantly from utilizing the GPU.Conclusions. It is concluded that the tile-based approach works welland creates a functional terrain. However performance is too poor forthe technique to be utilized in e.g. a video game.

Keywords: Procedural Terrain Generation, Multi-threading, Perfor-mance.

i

List of Figures

1.1 The draw pipeline Direct3D version 11. . . . . . . . . . . . . . . 41.2 The dispatch pipeline Direct3D version 11. . . . . . . . . . . . . 5

4.1 Tile expansion as the user moves over the terrain. . . . . . . . . 114.2 A screenshot where heightmap and a simple grass texture have

been aplied. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3 A screenshot with more elaborate texturing. . . . . . . . . . . . . 144.4 A screenshot of a river created by software agents. . . . . . . . . 164.5 A screenshot of a road created by software agents. . . . . . . . . 17

6.1 Comparison of execution times (in ms) between CPU and GPU. . 216.2 Comparison of execution times (in ms) between di�erent thread

group sizes on the GPU. . . . . . . . . . . . . . . . . . . . . . . . 226.3 Comparison of execution times (in ms) with and without software

agents on the CPU. . . . . . . . . . . . . . . . . . . . . . . . . . 236.4 Comparison of execution times (in ms) with and without software

agents on the GPU. . . . . . . . . . . . . . . . . . . . . . . . . . 24

ii

List of Tables

4.1 Values for variables used to control the fractal function. . . . . . 12

5.1 Hardware speci�cation for the PC used in the experiment. . . . . 20

6.1 Comparison of execution times (in ms) between CPU and GPU. . 226.2 Comparison of execution times (in ms) between di�erent thread

group sizes on the GPU. . . . . . . . . . . . . . . . . . . . . . . . 226.3 Comparison of execution times (in ms) with and without software

agents on the CPU. . . . . . . . . . . . . . . . . . . . . . . . . . 236.4 Comparison of execution times (in ms) with and without software

agents on the GPU. . . . . . . . . . . . . . . . . . . . . . . . . . 24

7.1 Frame rate expressed as maximum time each frame is allowed totake in ms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7.2 Results from a students t test on the collected data for the CPU/GPUcomparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

iii

Contents

Abstract i

1 Introduction 1

1.1 Procedural Content Generation . . . . . . . . . . . . . . . . . . . 21.2 Noise and Fractals . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 GPU Programming and The Compute Shader . . . . . . . . . . . 31.4 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Aim and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Related Work 7

3 Method 9

4 Implementation 11

4.1 Heightmap Generation . . . . . . . . . . . . . . . . . . . . . . . . 124.1.1 Heightmap Generation GPU . . . . . . . . . . . . . . . . . 13

4.2 Software Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3 Deterministic Tiles . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Experiment 19

6 Results 21

7 Analysis 25

8 Discussion 27

8.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

References 29

iv

Chapter 1

Introduction

Procedural Content Generation (PCG) concerns creating content using algo-rithms, meaning no human designer or artist is needed. This has the possibility toshorten development time, cut costs and potentially inspire new types of contentand gameplay. Procedural Terrain Generation (PTG) is a sub-set of PCG thatconcerns speci�cally the creation of terrains.

In this study an application that allows the user to walk around on a proce-durally generated terrain is developed. A tile-based approach is used and as theuser gets close to the edge of the terrain new tiles are generated along that edge.Tiles that the user have moved away from are removed once a certain distanceis reached between the tile and the user. In this way a seemingly endless terrainis created. To add more detail to the terrain software agents will be used tocreate rivers and roads. The application is developed in two versions: one versionthat exclusively utilizes the CPU and one optimized version that utilizes bothCPU and GPU when generating the terrain. An experiment is conducted thatmeasures performance of the two versions for di�erent tile sizes. The purpose isto determine if real-time performance on the CPU is possible, at which tile sizereal-time performance is no longer possible on the CPU, if the application willbene�t from GPU utilization and if so at which tile size GPU utilization becomesmore e�ective than exclusively utilizing the CPU.

When generating the terrain larger tiles are preferable since that would allowfor the user to view more of the terrain at once making the application morevisually impressive. However as tile sizes increase as does the time for generatingthem. Larger tiles means that more height values needs to be calculated and thatthe software agents have a larger data set to traverse.

Terrains are an important piece of content in many video games and otherforms of simulations [8, 23]. Quite a few studies exists in the area of proceduralterrain generation, however few of these studies concern performing the generationin real-time and as far the author is aware this study is unique in that it developsa tile-based method for generating a seemingly endless terrain.

1

Chapter 1. Introduction 2

1.1 Procedural Content Generation

PCG is "the algorithmical creation of game content with limited or indirect userinput" [25]. Where content refers to things such as, terrain, levels, cities, equip-ment, dialogue, etc. PCG is interesting for developers to look at for a number ofdi�erent reasons.

Video games require a huge amount of content with high detail to meet playerexpectations that continually rises as games become more complex and grows inscope [6]. Creating all this content by hand can be both time consuming andexpensive. PCG used both o�ine and online can speed up the development andmitigate high costs. However creating a program that can create accurate andfun content can be very di�cult.

O�ine PCG is when content is generated during development and the �n-ished game ships with all its content already generated. This lowers the demandfor the algorithms to create accurate content since faulty or vapid content can bediscarded, or be handed of to a human designer who can �x problems or add moredetail. It also has the possibility to serve as a source of inspiration for humancontent creators. The algorithms are not constrained by our limited human imag-ination and could possibly produce content that a human designer never wouldhave thought of.

Online PCG on the other hand is when the game generates content as the gameis played, either during start up or in real-time during gameplay. This can increasethe replay value of a game by o�ering new experiences to the player every time hereturns to the game. It also allows for the emergence of new styles of gameplaythat centres around procedurally generated content [24]. If the PCG-algorithmsused can be made e�cient enough and consistently create novel content it opensup the possibility for truly endless games where, wherever the player goes thereare new areas to explore and new things to do. The generation of content couldalso be adjusted to suit a particular playing style or skill level.

1.2 Noise and Fractals

Common techniques when generating terrains include noise and fractals, eitherused by themselves or combined to create a heightmap that control the terrain'selevation. In the context of computer graphics noise is an apparently stochasticirregular function. Noise is often used in procedural texturing with the purpose ofintroducing randomness to patterns that would otherwise look too monotone toappear natural. It is often desirable that noise exhibits the following properties:

� It is repeatable of its inputs, meaning that the same input always returnsthe same output.

� It has a range that is known, usually between -1 and 1.

Chapter 1. Introduction 3

� It is not obviously periodic. Pseudorandom functions always exhibit somelevel of periodicity, however the period can be made long enough that it isnot noticeable.

A popular noise function is Perlin Noise created by Ken Perlin in 1983 [18].The function divides the texture space into a lattice where each lattice pointcontains a pseudorandom wavelet. The function computes a noise value for agiven coordinate by determining which cell the coordinate belongs to, computingthe wavelets for the lattice points in each corner of that cell and then summarizingthe wavelets. In 2002 Ken Perlin made some improvements to his noise function.The improved version is called Improved Perlin Noise and sometimes SimplexNoise. Improved Perlin noise has been shown to generate better looking noiseand also running up to 10% faster than the original noise function [21].

A fractal can be de�ned as "a geometrically complex object, the complexity ofwhich arises through the repetition of a given form over a range of scales" [18].The "given form" can also be called a basis function. This function can be justabout anything, common examples include: an image, a noise function, etc. Frac-tals can be used to model a number of di�erent natural phenomena. Mountainsare a good example, a smaller part of a mountain looks just as much as a mountainas a larger part. Trees are another example where smaller branches are visuallysimilar to larger ones.

Fractal dimension is the relationship between frequency and amplitude whichdetermines roughness. A terrain generated with a uniform dimension will havethe same roughness everywhere. When looking at a real terrain there are oftensmooth hills and valleys, rocky patches and mountains with a much more roughsurface rising from the more smooth ground. By using multifractals which alterstheir dimension depending on location much more realistic terrain with a varyingroughness can be created.

1.3 GPU Programming and The Compute Shader

In 2001 NVIDIA released GeForce 3 which was the �rst GPU to support pro-grammable vertex shaders, exposed through DirectX 8 and extensions toOpenGL [1]. Since then GPUs have continued to become more powerful andprogrammable and have more and more started to resemble parallel computers.This has made it possible to use GPUs for other forms of calculations than thosestrictly tied in with graphics. Problems of a high computational cost that ex-hibit some level of parallelism can be implemented to run on a GPU to receive asigni�cant speed-up.

Current graphics pipelines work by moving data through a set of steps calledshaders in a predetermined order. Direct3D version 11 supports two di�erentkinds of pipelines. There is the draw pipeline (see �gure 1.1) that works as

Chapter 1. Introduction 4

explained above by moving data through shaders. Then there is the dispatch, orcompute shader pipeline (see �gure 1.2) that exists outside the draw pipeline andallows for programmers to view the GPU as a generic grid of parallel processors.This allows the programmer to utilize the GPU for general purpose calculationswithout being forced to render geometry or cast information into textures.

Figure 1.1: The draw pipeline Direct3D version 11.

A compute shader is invoked by making a call to a dispatch method [14]. Thiscall will dispatch a grid where each cell contains a thread group, which size hasbeen speci�ed in the shader. Di�erent thread group sizes can have impacts onperformance since it determines how threads are scheduled and memory usage.Threads and thread groups can be identi�ed using system values such as e.g.SV_DispatchThreadID which contains the thread's x and y coordinate in thegrid.

Chapter 1. Introduction 5

Figure 1.2: The dispatch pipeline Direct3D version 11.

1.4 Problem Statement

A lot of work has been done in the area of PTG. However very few of the studiesthat exists conducts the generation in real-time and none of the studies the authorhas been able to �nd allows for the terrain to expand as the user moves over it.Utilizing online PTG and allowing the terrain to expand in real-time could allowfor some interesting properties in a game utilizing this technique:

� It creates a seemingly endless world. Some limitations exists that preventsthe terrain from being actually endless but it allows the player to move agreat distance before hitting the edge.

� The amount of disk space needed for the game is reduced since the terraindoes not exist until the game is played.

� If coupled with a learning algorithm the game could adjust the terraingeneration to suit a particular playing style or skill level.

The purpose of this study is to investigate a tile-based technique for gener-ating a terrain that can expand in real-time. For each tile a heightmap will begenerated. However a simple heightmap would create a rather bland and unin-teresting terrain. When considering a video game context a player would likelywant to see more details such as e.g. di�erent colouring of the ground, forests,rivers, etc. This has been taken into account in this study by employing a simplecolouring technique for the terrain as well as software agents that will add riversand roads. The additional detail serves to more accurately estimate performancecosts, were the technique to be used in e.g. a video game. Additionally the use ofsoftware agents further validates the tile-based technique by showing that changesto the terrain does not need to be localized to a single tile but rather can extendover multiple tiles, that are largely independent, without artefacts such as e.g.tearing.

Chapter 1. Introduction 6

1.5 Aim and Objectives

The aim of this study is to test if real-time performance of procedural generationof a seemingly endless terrain using the "Ridged Multifractal Terrain Model" incombination with software agents is possible on the CPU. It will also investigatepossible performance increases by moving parts of the proposed algorithm to theGPU.

To achieve this the following steps are completed:

1. An algorithm for generating heightmaps is selected, in this case the "RidgedMultifractal Terrain Model" [18].

2. The heightmap generation algorithm, as well as a method for tiling piecesof terrain are implemented, exclusively utilizing the CPU.

3. Software agents are implemented that can traverse the terrain and createrivers and roads, also utilizing the CPU.

4. An alternate version of the heightmap generation algorithm is implemented,utilizing the GPU.

5. An experiment is conducted that measures the performance of the two dif-ferent versions of the application.

Chapter 2

Related Work

Musgrave et al. [18] describes what fractals are and how they can be used to modelnatural phenomena. Musgrave then goes on to present a number of ontogeneticmodels for generating terrains that are designed to approximate certain erosionfeatures. The models are varieties of multifractals and among them the "RidgedMultifractal Terrain Model", which will be utilized in this project, can be found.

Génevaux et al. [9] created terrains by simulating hydrological erosion. Theuser provides a sketch as well as a couple of input parameters. The sketch containsthe terrain outlines, river mouths and some river parts. From this the algorithmcreates a river network represented by a graph. The output from the river gen-eration is a set of 3D polylines describing river elevations. The rivers are thencategorised into procedural primitives such as junctions, springs, deltas, and rivertrajectories that are used in the �nal rendering. When the river network has beencompleted topology data is extracted from the graph for use when constructingthe terrain.

Togelius et. al. [26] proposes a search-based procedural content generationalgorithm for strategy game maps. Five objectives that determines player ex-perience are de�ned and a multiobjective evolutionary algorithm is created thatsearches for maps that satis�es pairs of these objectives. Since the objectives arecon�icting Pareto fronts are used to show how the objectives are balanced. Themap generation starts with a �at grid upon which bases, resources and mountainsare placed. The mountains are generated with the use of Gaussian curves drawnin two dimensions.

Doran and Parberry [6] explores a method that will give the user more controlover how the terrain is generated. This is achieved by using intelligent softwareagents and allowing the user to control the constraints on those agents. Theterrain generation is divided into three phases. In the �rst, or coastline phase,agents work to outline a landmass, that could possibly be surrounded by water. Inthe second, or landform phase, a larger number of agents move over the landmassto create beaches, hills, mountains, etc. In the �nal phase, the erosion phase,rivers are created by eroding parts of the terrain.

Olsen [20] created eroded fractal terrains in real-time. However Olsen usesa di�erent de�nition of real-time than what will be used here. His algorithm

7

Chapter 2. Related Work 8

generates terrains in a couple of seconds which is deemed acceptable since it isnot uncommon for games to have loading times of up to 30 seconds [20]. The baseterrain is created with the use of 1/f noise combined with Voronoi diagrams. Theterrain is then eroded using a speed optimized thermal erosion algorithm that hasbeen modi�ed to emulate properties of hydraulic erosion.

Mistal [12] presents a GPU-based algorithm that can be used for terrain ren-dering. The algorithm can create and subdivide a large mesh with distance basedlevel of detail. The height values for each vertex in the terrain are procedu-rally generated using the "Ridged Multifractal Terrain Model" described by Mus-grave [18]. The algorithm runs in real-time and achieves good performance.

This project di�ers from the above mentioned studies in that it aims to createa seemingly endless terrain generated in real-time using a tile based solution. Allof the above mentioned studies uses a �nite size on the terrain and only one ofthem [12] achieves real-time performance. This project will be using softwareagents to add more detail to the heightmap (that has been generated using frac-tals) similar to those described by Doran and Parberry [6]. However the agentsin this project will be working under more strict performance requirements.

Chapter 3

Method

This study uses quantitative research methods. First an application is imple-mented to later be used in an experiment that measures the application's perfor-mance. The experiment is run several times with di�erent con�gurations of theapplication and measures the time it takes to generate new tiles each time theterrain expands. The result from each run of the experiment is a series of timevalues that can be compared to determine how the application's performancechanges for di�erent con�gurations.

When generating the terrain larger tiles are preferable since that would allowfor the user to view more of the terrain at once making the application morevisually impressive. However as tile size increase as does the time for generatingthem. Larger tiles means that more height values needs to be generated and thatthe software agents have a larger data set to traverse. This project proposes totry and answer the following questions:

� RQ1: Can seemingly in�nitely large terrains be created on the CPU inreal-time by tiling pieces of terrain that have been procedurally generatedusing the "Ridged Multifractal Terrain Model" to create heightmaps andsoftware agents to add more detail in the form of rivers and roads?

� RQ2: How large can tiles be before real-time performance on the CPU isno longer possible?

� RQ3: At which tile size does the application start to bene�t from GPUutilization?

An application starts becoming interactive at around 6 frames per second(fps) [1]. 15 fps can de�nitely be thought of as real-time. There is a noticeabledrop in user performance when moving below 15 fps and only a modest increasewhen moving from 15 fps and up to 30 fps [5]. However Regan et al. [22] hasfound that human users can experience latency artefacts with a latency as low as15 ms (around 67 fps). The most commonly occurring frame rates in video gamesare either 30 or 60 fps [2]. 15 fps is real-time, however if the method presentedin this study is to be used in a video game context its performance should be atleast 30 fps.

9

Chapter 3. Method 10

To answer the questions above an application is developed that allows for theuser to walk around on a procedurally generated seemingly endless terrain. Theterrain will be generated in tiles. The height map for each tile will be generatedusing the "Ridged Multifractal Terrain Model". When the heightmap has beengenerated software agents will move over the terrain and add more details suchas rivers and roads. The application is developed in two version. One thatexclusively utilizes the CPU and one version where the "Ridged MultifractalTerrain Model" calculations have been moved to the GPU.

An experiment is then conducted where performance is measured for di�erentcon�gurations of the application. All con�gurations of the application are runonce for each tile size being tested. The tile sizes used in the experiment are64x64, 128x128, 256x256 and 512x512.

Chapter 4

Implementation

An application was developed using C++ and Direct3D 11 that allows the userto walk around on a procedurally generated terrain. The terrain generation istile-based. At start-up a tile is created with its center at (0, 0) as well as eighttiles surrounding the original tile. The user starts at position (0, 0) and can movearound on the terrain as he pleases. When the user crosses over to an adjacenttile, new tiles are generated in the available spaces around the tile that the usercrossed over to (see �gure 4.1). When the user has moved a certain distance awayfrom a tile, that tile is removed.

Figure 4.1: Tile expansion as the user moves over the terrain.

At start-up a grid is generated with the input parameters: width, depth,number of columns and number of rows. This results in a grid consisting of num-ber of rows times number of columns vertices with one end of its diagonal in(−width

2, −depth

2) and the opposite end in (width

2, depth

2). Each vertex contains a posi-

tion, a surface normal and texture coordinates. At this point the vertex positionsare in local space and are later translated by the tile object to world space. Sincethe grid is �at the normals all have the value (0.0, 1.0, 0.0) and will be recalcu-lated once a heightmap has been generated. The texture coordinates ranges from

11

Chapter 4. Implementation 12

(0.0, 0.0) to (1.0, 1.0). The textures used on the terrain are all seamless allowingfor them to be repeated several times over the terrain by scaling up the texturecoordinates in the shader during rendering. This allows for textures with a lowerresolution and makes sure there are smooth color transitions between tiles.

4.1 Heightmap Generation

When a new tile is being generated the grid is copied to the new tile object. Aheightmap is then generated using the "Ridged Multifractal Terrain Model" [18].The fractal function's output can be controlled by changing the values of �vedi�erent variables: number of octaves, dimension, lacunarity, o�set and gain.Octaves is the number of repetitions in the fractal. Dimension is the relationshipbetween frequency and amplitude which determines the roughness of the gener-ated terrain. Lacunarity determines the size of the gap between frequencies usedin the fractal construction. O�set controls the multifractality of the function. Aso�set increases the function will go from multifractal to monofractal and eventu-ally approach a �at plane. Gain controls the amplitude of the signal output bythe fractal function. The values used for these variables is presented in table 4.1.The values were selected based on recommendations in [18] and trial-and-error.

Variable Name Value

Octaves 8Dimension 2.0Lacunarity 2.5O�set 1.0Gain 2.0

Table 4.1: Values for variables used to control the fractal function.

As a basis function for the fractal, a gradient noise function called SimplexNoise is utilized. The fractal function is run for each vertex in the grid generatinga height value. It takes the vertex's x- and z-coordinates, translated to worldspace, as input. These coordinates are then used by the fractal function as inputto the noise function. To avoid big leaps between noise values for neighbouringvertices the coordinates used as input are scaled down by a factor of 1400. Asample of the resulting heightmap can be seen in �gure 4.2.

When the heightmap has been generated the height values are applied to thevertices in the grid. Normals are then calculated for each vertex in the grid toallow for lighting calculations to be performed when the terrain is rendered. Thenormals are also used to texture the terrain. From the beginning the terrain hasa grass texture applied to it. For each vertex a dot product is calculated betweenits normal and a vector aimed straight up, that value is then ampli�ed (multipliedby �ve in this case) and written to a blend map that when rendering is used to

Chapter 4. Implementation 13

Figure 4.2: A screenshot where heightmap and a simple grass texture have beenaplied.

blend in stone and dirt textures. The result (which can be viewed in �gure 4.3)is a more varied colouring of the terrain where steeper angels are textured withrock and dirt instead of grass.

4.1.1 Heightmap Generation GPU

The CPU version of the fractal function is sequential stepping through each ver-tex one at a time. However the "Ridged Multifractal Terrain Model" allows foreach point to be evaluated individually making it suitable for a parallel imple-mentation. As an attempt at optimization another version of the fractal functiondescribed above was implemented on the GPU using the compute shader in Di-rect3D 11. The author is aware that there are other programming models thatcan be used in order utilize the GPU for general purpose calculations such asOpenCL [10], CUDA [19] or C++ Amp [13]. However due to previous experienceworking with the compute shader and the fact that the application uses DirectXfor rendering, the compute shader was chosen to reduce development time. Thereare several performance comparisons between CUDA and OpenCL [11, 7, 4, 3, 17].The author has however been unable to �nd any such comparisons that includethe compute shader or C++ Amp.

There are a number of di�erent ways a resource can be bound to a shader. Inthis application the following were used: the shader resource view, the constant

Chapter 4. Implementation 14

Figure 4.3: A screenshot with more elaborate texturing.

bu�er and the unordered access view.

� A shader resource view (SRV) is a read only resource that can be bound toany shader stage. A common use of SRVs are to bind textures to a shader.

� A constant bu�er (cbu�er) is a read only resource on the GPU that can beupdated frequently by the CPU between calls to the GPU. It is commonlyused to store variables such as camera data or transformation matrices.

� Unordered access views (UAV) were introduced in Direct3D 11 and can bebound only to pixel and compute shaders. The GPU has both read andwrite access to this type of resource.

Heightmap array that will contain the �nished heightmap is bound to theshader as a UAV. Data that is needed by the noise function such as permutationtables, gradients and exponents are created on the CPU during start-up of theapplication and are bound to the shader as SRVs. The following variables arebound to the shader via a constant bu�er:

� Tile position.

� Tile width.

� Tile depth.

Chapter 4. Implementation 15

� Tile number of columns.

� Tile number of rows.

� Two constants used by the noise function that are calculated at start up.

� Number of octaves.

� Fractal dimension.

� Lacunarity.

The compute shader is dispatched with an equal number of threads that thereare vertices in the grid. Since the grid is not copied to the GPU vertex positionsneeds to be calculated to be used input to the noise function. This is done usingtile width/depth, tile number of columns/rows, tile position and thread id asshown in listing 4.1. Other than that the fractal function looks the same as itdoes on the CPU.

Listing 4.1: Calculating position using thread id

pos . x = −(width /2 . 0 ) + threadId . x * ( width /( colCnt −1)) ;pos . y = ( depth /2 . 0 ) − threadId . y * ( depth /( rowCnt−1)) ;pos . x += ti l ePosX ;pos . y += ti l ePosY ;

A resource that has been created with read/write access on the GPU can notbe read by the CPU. Therefore once the compute shader is �nished the heightmapdata needs to be copied to a resource that the CPU has read access to before thedata can be used in the subsequent steps in the terrain generation.

4.2 Software Agents

To add more detail to the terrain software agents were utilized to create riversand roads. The agents use a greedy search algorithm to �nd suitable verticesin the grid that they can add to their path. The agents are given a vertex inthe grid as their starting location and a direction that they aim to move along.The starting vertex is added to the closed list and set as the current node. Thealgorithm will look at the current node's neighbours along the x- and z-axis, itdoes not move diagonally. If the neighbouring node is valid i.e. in bounds andnot already evaluated, it will be given a value by a heuristic function and beadded to the open list. The open list is sorted in ascending order according tothe nodes heuristic values. The node at the front of the open list is added to theclosed list and the open list is emptied. The last node in the closed list is set asthe current node and the algorithm starts over looking at the neighbours. Thealgorithm continues like this until a stopping criteria is met.

Chapter 4. Implementation 16

Agents will stop if they encounter the edge of tile. If that edge is adjacent toan already existing tile one of two things will happen.

� If the agents has already crossed tiles once, it will be marked as �nishedand remove one third of the nodes starting from the back of the closed list.This is to remove the noticeable edge that would otherwise appear betweentiles.

� If the agent is on its starting tile it will be removed completely.

The agents are not allowed to cross over to already existing tiles since it wouldbe strange if a tile already seen by the user changed its appearance. On the otherhand if there is empty space along the edge where the agent stopped it will bemarked as incomplete and its last node will be saved so that the agent can crossover once a tile is being generated adjacent to that edge.

Figure 4.4: A screenshot of a river created by software agents.

When a new tile is being generated it will check if its neighbours have an agentthat wants to cross over to it. If that is the case the tile will create an agent thatstarts where the neighbour's agent stopped. If no agents are trying to cross over,the tile will start on a new river or road, or both. Since water tends �ow in adownwards direction rivers will start on the highest location on the tile. It doesnot necessarily need to be the highest location as long as it is high, however thehighest is the easiest to �nd without having to sort the values in the heightmap.Roads are simply given the middle of the tile as a starting location. Agents will

Chapter 4. Implementation 17

be given the same direction as the new tile is being generated in, e.g. if the newtile is to the left of the current tile the agent will try to move to the left. Thisis done in an attempt to keep the agent from running into already existing tilesand thus being cut short.

The river agents use a heuristic function that will lower a nodes heuristicvalue if the node is in the same direction the agent has been assigned to follow.If the node has a height value lower than the current node it will lower the node'sheuristic value, if the node has a greater height value than the current node itwill give the node a greater heuristic value. If the agent's only option is a nodewith a heuristic value that is too great the agent will mark itself as �nished andstop since this means that the agent's only option is to travel uphill and watertends to �ow downhill.

Once a path has been found the path is traversed and the surrounding areais modi�ed. The terrain is eroded to create a riverbed which is also given a sandtexture by writing to a blend map. The results of this process can be seen in�gure 4.4.

Figure 4.5: A screenshot of a road created by software agents.

Unlike the river agents, road agents do not look at the closest neighbours tothe current node. Instead they look seven steps ahead. This is due to the factthat the agents have a tendency to do a zigzag pattern, which gave satisfyingresults for rivers, making them wider in certain places, but looks unnatural forroads. Increasing the distance between nodes added to the path remedied thisproblem. Road agents are also not allowed to move opposite the direction they

Chapter 4. Implementation 18

have been assigned to follow. Road agents often made u-turns and ran into nodesthat had already been added to the path causing them to get stuck. The roadagents use a heuristic function that is similar to the one river agents use in that itlowers the heuristic value of a node that is in the same direction as the agent hasbeen told to follow. But instead of looking at height values this heuristic functionlooks at the angle between the normal and a vector aimed straight up, where asmall angle lowers the score and big angle raises it. These angles have alreadybeen calculated when texturing the terrain and can thus be read from the blendmap (see section 4.1). This causes the agent to keep to �at ground and avoidmoving up and down steep inclinations.

Just like the river agents, once a path has been found the path is traversedand the terrain modi�ed. In this case no changes to the geometry is done, onlythe texture is changed to give the look of a dirt road. An example of this can beseen in �gure 4.5.

4.3 Deterministic Tiles

In order to make the tile generation deterministic so that the terrain looks thesame when the user returns to a previously visited area data on each tile mustbe saved as the tile is generated the �rst time. Each time a new tile is generateda struct containing the following data is saved to an array:

� Tile position.

� River start position.

� River direction.

� Road start position.

� Road direction.

After new elements have been added to the array it is sorted in ascendingorder based on tile position using heapsort to allow for faster searching usingbinary search. When a new tile is generated it will �rst search through this arrayto see if there previously has been a tile located at the same position. If a matchis found the information above can be used to recreate the tile. If the directionfor either river or road is zero that means this tile does not have a river or road.No information needs to be saved to recreate the heightmap since the input tothe fractal function (which always gives the same output for a given input) is thevertex position, which does not change.

Chapter 5

Experiment

An experiment was conducted that measured the performance of the applica-tion with di�erent con�gurations for four di�erent tile sizes. The aim is to �ndout performance di�erences between CPU and GPU and how much the softwareagents impact on performance.

During the experiment the user had no control of the application, the cam-era moved by itself at a constant velocity making a ninety degree turn everyminute. Control of the camera was taken away from the user to ensure the samemovement pattern each time the application was executed. The same movementpattern means the same number of tiles are generated and that rivers and roadsare created the same way since they depend on which direction the user is movingin. Each time the application was executed it ran for �ve minutes. Each time theterrain expanded time was measured to see how long it took for all of the newtiles to be generated. Most commonly three to �ve tiles are generated each timethe terrain expands (see �gure 4.1). Time was measured using the QueryPer-formanceCounter [15] and QueryPerformanceFrequency [16] functions. Once theapplication had �nished, a mean value and standard deviation was calculated andwritten to �le along with all the collected time stamps. The following four tilesizes were tested:

� 64x64

� 128x128

� 256x256

� 512x512

These four sizes were tested on the CPU, with and without river/road agents,and on the GPU, with and without river/road agents. The GPU version wasalso tested with 3 di�erent thread group sizes: 8x8x1, 16x16x1 and 32x32x1.The results of the experiment can be viewed in chapter 6. The experiment wasexecuted on PC with the hardware speci�cation presented in table 5.1.

No attempts to evaluate the visual quality of the terrain was made duringthe experiment. The terrain was surveyed by the author to some extent during

19

Chapter 5. Experiment 20

Operating System Windows 8.1 Pro, 64-bit

CPU Intel Core i7-2600K 3,40 GHzRAM 8 GB DDR3 1600 MHzGPU NVIDIA GeForce GTX 460 1 GB GDDR5

GPU Driver Version 332.21

Table 5.1: Hardware speci�cation for the PC used in the experiment.

development to make sure the algorithm delivered visual quality to the author'sliking and not producing faulty content such as e.g. tearing between tiles, agentsbehaving in a manner they are not suppose to, etc. However this experiment isstrictly focused on the performance of the application.

Chapter 6

Results

The experiment yielded results that shows that the application bene�ts signi�-cantly from GPU utilization. As can be seen from �gure 6.1 the GPU is slightlyfaster than the CPU at tile size 64x64. As the tiles increase in size the GPUstarts to pull a head more and more. At tile size 512x512 the GPU is more thantwice as fast as the CPU.

0

100

200

300

400

500

600

64X64 128x128 256x256 512x512

Ela

psed

Tim

e In

ms

Terrain Tile Size

CPU GPU Comparison

CPUGPU

Figure 6.1: Comparison of execution times (in ms) between CPU and GPU.

When comparing di�erent thread group sizes on the GPU only small di�er-ences in performance between the di�erent group sizes were detected (see �g-ure 6.2). The di�erence between fastest and slowest for the di�erent tile sizesranges between less than a millisecond to 2.6 milliseconds.

Running the application without software agents on both CPU and GPUshowed a small performance increase. It also revealed the heightmap generationas the part of the algorithm taking the most time.

21

Chapter 6. Results 22

Tile Size CPU GPU

64x64 19.1 14.6

128x128 56.2 35.1

256x256 145.4 74.3

512x512 536.0 249.8

Table 6.1: Comparison of execution times (in ms) between CPU and GPU.

0

50

100

150

200

250

300

64x64 128x128256x256512x512

Ela

psed

Tim

e In

ms

Terrain Tile Size

GPU Thread Group Size Comparison

8x816x1632x32

Figure 6.2: Comparison of execution times (in ms) between di�erent thread groupsizes on the GPU.

TileSize 8x8 16x16 32x32

64x64 14.63 15.51 14.91128x128 35.14 35.96 36.63256x256 75.79 74.92 74.26512x512 252.4 249.8 252.0

Table 6.2: Comparison of execution times (in ms) between di�erent thread groupsizes on the GPU.

Chapter 6. Results 23

0

100

200

300

400

500

600

64x64 128x128 256x256 512x512

Ela

psed

Tim

e In

ms

Terrain Tile Size

CPU Agent Comparison

OnOff

Figure 6.3: Comparison of execution times (in ms) with and without softwareagents on the CPU.

Tile Size Agents On Agents O�64x64 19.08 6.786128x128 56.17 40.29256x256 145.5 121.3512x512 536.0 457.3

Table 6.3: Comparison of execution times (in ms) with and without softwareagents on the CPU.

Chapter 6. Results 24

0

50

100

150

200

250

300

64x64 128x128 256x256 512x512

Ela

psed

Tim

e In

ms

Terrain Tile Size

GPU Agent Comparison

OnOff

Figure 6.4: Comparison of execution times (in ms) with and without softwareagents on the GPU.

Tile Size Agents On Agents O�64x64 14.63 6.932128x128 35.14 22.43256x256 74.26 53.52512x512 249.8 179.4

Table 6.4: Comparison of execution times (in ms) with and without softwareagents on the GPU.

Chapter 7

Analysis

As mentioned in the method chapter, real-time was de�ned as at least 15 fpsand it was stated that most video games run at either 30 or 60 fps. For easiercomparison with the data presented in chapter 6 these values have been expressedin the maximum amount of time each frame is allowed to take if the frame rateis to be achieved in table 7.1.

FPS ms

15 67

30 33

60 17

Table 7.1: Frame rate expressed as maximum time each frame is allowed to takein ms.

When comparing these values to the results presented in table 6.1 we can seethat the CPU does indeed create tiles in real-time for the tile sizes 64x64 and128x128. Once a size of 256x256 is reached however the CPU is far past the limitfor what can be considered as real-time. The GPU version of the application isalso capable of creating tiles in real-time for the sizes 64x64 and 128x128. Eventhough the GPU version is signi�cantly faster than the CPU it still takes too longto be considered real-time once tiles reaches the size of 256x256. This answersboth RQ1 and RQ2.

It is worth noting that even though the tile size 128x128 can de�nitely beconsidered to be generated in real-time it is not fast enough for most video games.Additional speed-up would be required for this to be applicable as anything morethan a tech-demo. This is especially true when considering what is measuredhere is strictly the time for generating tiles, in e.g. a video game time will alsobe spent each frame on things such as game logic, physics, etc.

To answer RQ3, we need only to look at �gure 6.1 which shows that the GPUis faster than the CPU already at the smallest tile size tested.

To ensure that the values used for the CPU/GPU comparison are statistically

25

Chapter 7. Analysis 26

Tile Size t test Signi�cance Probability

64x64 3.5 ∗ 10−24 100%128x128 5.3 ∗ 10−64 100%256x256 1.2 ∗ 10−98 100%512x512 2.1 ∗ 10−73 100%

Table 7.2: Results from a students t test on the collected data for the CPU/GPUcomparison.

signi�cant a two-tailed unpaired t-test was performed. The t-test revealed thatthe probability that the values used in the comparison are statistically signi�cantis close 100% for each tile size (see table 7.2).

Chapter 8

Discussion

The terrain created in this study is actually not endless. As stated in section 4.2a small amount of data needs to be stored for each tile to be able to recreateit. This small amount is 40 bytes. Which when considering how much memorywould be required to store an entire tile, where each vertex is 32 bytes, is notthat bad. Still once the user have crossed enough tiles the computer will run outof memory.

Besides memory usage there is another limiting factor that prevents the terrainfrom being endless. The tile coordinates are stored in a 32-bit �oat variable whichcannot grow inde�nitely. Granted the user have to have moved a great distancebefore this becomes an issue which could be further postponed by using a 64-bitdouble variable instead but the limit is still there.

8.1 Conclusions

An application was developed that allows the user to walk around on a tile-basedprocedurally generated terrain. The application was developed in two versions:one that exclusively utilizes the CPU and one that utilizes both CPU and GPU forgenerating the terrain. Performance was measured in order to answer questionsstated in chapter 3.

The results showed that it was indeed possible to run the application withreal-time performance on the CPU for two of the tested tile sizes: 64x64 and128x128. At tile sizes of 256x256 real-time performance was no longer possibleon the CPU. The GPU version was faster than the CPU version for all tile sizes.Even though the GPU version was signi�cantly faster than the CPU version itwas not fast enough to achieve real-time performance on tiles of 256x256 andlarger.

It was also shown that while tiles with the size 128x128 could be generatedin real-time it was not fast enough for most video games. This means that outof the four tile sizes tested, the smallest (64x64) is the only one that can begenerated fast enough for use in a video game. However, 64x64 is a fairly smallsize resulting in relatively unimpressive terrain. The technique demonstrated in

27

Chapter 8. Discussion 28

this study is thus not suitable to be used in a video game context without furtherimprovements to its performance.

While the application still was not fast enough for use in video games, theGPU proved a powerful tool in speeding up the application. At larger tile sizes theGPU version became more than twice as fast. Utilization of the GPU is de�nitelysomething that is worth considering when working with PTG-algorithms thatexhibit a similar level of parallelism.

Despite poor performance at larger tile sizes the tile based approach produceda functional terrain. This shows that a tile based approach is feasible for creatinga large terrain and is viable for further investigation to see if performance can beimproved in order to make the technique suitable for a video game or a similartype of application.

8.2 Future Work

Figure 6.3 and �gure 6.4 showed that removing the software agents gave an in-crease in performance but that most of the work was done by the heightmap gen-eration. It would be interesting to investigate further optimizations that could bedone to that part for the code. One example could be to better tailor the fractalfunction to the GPU to better tap in to the computing power of the GPU.

Another interesting thing to look at would be to split up the tile generationover several frames. As shown in �gure 4.1 when the terrain expands three to �vetiles are generated. By splitting them up and generating only on tile per frameone might cut the execution times presented in this study by approximately twothirds. One might also consider to instead of using few large tiles to use a largeramount of small tiles having two or more layers surrounding the tile the user ison instead if just one as shown in �gure 4.1. This could also be coupled with alevel of detail algorithm allowing for tiles further away to stay partially generateduntil the user gets close enough notice a di�erence, thus spreading the workloadover several frames.

References

[1] Tomas Akenine-Möller, Eric Haines, and Naty Ho�man. Real-Time Render-ing. A K Peters, Ltd., 3rd edition, 2008.

[2] Dmitry Andreev. Real-time frame rate up-conversion for video games: Orhow to get from 30 to 60 fps for "free". In ACM SIGGRAPH 2010 Talks,SIGGRAPH '10, pages 16:1�16:1, New York, NY, USA, 2010. ACM.

[3] J.P. Arun, M. Mishra, and S.V. Subramaniam. Parallel implementation ofmopso on gpu using opencl and cuda. In High Performance Computing(HiPC), 2011 18th International Conference on, pages 1�10, Dec 2011.

[4] G. Bernabe, G.D. Guerrero, and J. Fernandez. Cuda and opencl implemen-tations of 3d fast wavelet transform. In Circuits and Systems (LASCAS),2012 IEEE Third Latin American Symposium on, pages 1�4, Feb 2012.

[5] Mark Claypool and Kajal Claypool. Perspectives, frame rates and resolu-tions: It's all in the game. In Proceedings of the 4th International Conferenceon Foundations of Digital Games, FDG '09, pages 42�49, New York, NY,USA, 2009. ACM.

[6] J. Doran and I. Parberry. Controlled procedural terrain generation usingsoftware agents. Computational Intelligence and AI in Games, IEEE Trans-actions on, 2(2):111�119, June 2010.

[7] Jianbin Fang, A.L. Varbanescu, and H. Sips. A comprehensive performancecomparison of cuda and opencl. In Parallel Processing (ICPP), 2011 Inter-national Conference on, pages 216�225, Sept 2011.

[8] K.D. Forbus, J.V. Mahoney, and K. Dill. How qualitative spatial reasoningcan improve strategy game ais. Intelligent Systems, IEEE, 17(4):25�30, July2002.

[9] Jean-David Génevaux, Éric Galin, Eric Guérin, Adrien Peytavie, and Bed°ichBene². Terrain generation using procedural models based on hydrology. ACMTrans. Graph., 32(4):143:1�143:13, July 2013.

29

References 30

[10] Khronos Group. The open standard for parallel programming of hetero-geneous systems. https://www.khronos.org/opencl/. [Online; accessed12-02-2014].

[11] Kamran Karimi, Neil G. Dickson, and Firas Hamze. A performance com-parison of cuda and opencl. CoRR, abs/1005.2581, 2010.

[12] Benjamin Mistal. Gpu terrain subdivision and tesselation. In Engel Wolgang,editor, GPU Pro 4 Advanced Rendering Techniques, pages 3�20. A K Peters,2013.

[13] MSDN. C++ amp. http://msdn.microsoft.com/en-us/library/

hh265137.aspx. [Online; accessed 12-02-2014].

[14] MSDN. Id3d11devicecontext::dispatch method. http://msdn.microsoft.

com/en-us/library/windows/desktop/ff476405%28v=vs.85%29.aspx.[Online; accessed 13-05-2014].

[15] MSDN. Queryperformancecounter function. http://msdn.microsoft.com/en-us/library/windows/desktop/ms644904\%28v=vs.85\%29.aspx. [On-line; accessed 10-02-2014].

[16] MSDN. Queryperformancefrequency function. http://msdn.microsoft.

com/en-us/library/windows/desktop/ms644905\%28v=vs.85\%29.aspx.[Online; accessed 10-02-2014].

[17] S. Mukherjeet, N. Moore, J. Brock, and M. Leeser. Cuda and opencl imple-mentations of 3d ct reconstruction for biomedical imaging. In High Perfor-mance Extreme Computing (HPEC), 2012 IEEE Conference on, pages 1�6,Sept 2012.

[18] F. Kenton Musgrave, David S. Ebert, Darwyn Peachy, Ken Perlin, andSteven Worley. Texturing & Modeling: A Procedural Approach. MorganKaufmann Publishers, 3rd edition, 2003.

[19] NVIDIA. What is cuda. https://developer.nvidia.com/what-cuda. [On-line; accessed 12-02-2014].

[20] Jacob Olsen. Realtime procedural terrain generation - realtime synthesis oferoded fractal terrain for use in computer games, 2004.

[21] Ken Perlin. Improving noise. ACM Trans. Graph., 21(3):681�682, July 2002.

[22] Matthew J. P. Regan, Gavin S. P. Miller, Steven M. Rubin, and Chris Ko-gelnik. A real-time low-latency hardware light-�eld renderer. In Proceedingsof the 26th Annual Conference on Computer Graphics and Interactive Tech-niques, SIGGRAPH '99, pages 287�290, New York, NY, USA, 1999. ACMPress/Addison-Wesley Publishing Co.

References 31

[23] Ruben M. Smelik, Tim Tutenel, Klas Jan de Kraker, and Rafael Bidarra.Declarative terrain modeling for military training games. International Jour-nal of Computer Games Technology, 2010, 2010.

[24] Gillian Smith, Elaine Gan, Alexei Othenin-Girard, and Jim Whitehead. Pcg-based game design: Enabling new play experiences through procedural con-tent generation. In Proceedings of the 2Nd International Workshop on Pro-cedural Content Generation in Games, PCGames '11, pages 7:1�7:4, NewYork, NY, USA, 2011. ACM.

[25] Julian Togelius, Emil Kastbjerg, David Schedl, and Georgios N. Yannakakis.What is procedural content generation?: Mario on the borderline. In Proceed-ings of the 2Nd International Workshop on Procedural Content Generationin Games, PCGames '11, pages 3:1�3:6, New York, NY, USA, 2011. ACM.

[26] Julian Togelius, Mike Preuss, and Georgios N. Yannakakis. Towards multi-objective procedural map generation. In Proceedings of the 2010 Workshopon Procedural Content Generation in Games, PCGames '10, pages 3:1�3:8,New York, NY, USA, 2010. ACM.