Generating Planetary Terrain Procedurally

Like all computer science majors set to graduate this year, I have a capstone project to prepare. If you haven’t already guessed, mine is all about procedural generation. I choose a project that can be completed within four months in spite of my limited knowledge of computer graphics. My project is to procedurally generate terrain, wrap it around a sphere and then call it a planet.


In the process of making a video game, one of the most time-consuming task is content creation. As game worlds become larger and increasingly more complex, game designers and artists spend enormous amounts of time creating content for games. In a 3D space exploration game for example, they have to design and model hundreds of aesthetically distinct planets, meticulously crafting every detail by hand.

Procedurally generated terrain, courtesy of Martin Klekner.

In computer graphics, procedural generation is the process of generating content algorithmically rather than manually. My final year project involves building a prototype that can efficiently generate planetary terrain through procedural generation, meaning that it will generate terrain on the fly and without taking advantage of prerendered assets (except for textures). Focus will be on performance as well as easy customization of the terrain by providing an interface for designers and artists to tweak the variables. Content generation will be deterministic, meaning that for a given seed, the program will always generate the exact same planet. The twist in this project is the ability to pick one of the two predefined themes: fully realistic terrain (detailed and dry-colored land) or abstract-style terrain (simplified and colorful land).

The results of this research project can be of assistance to game developers, designers and artists for creating their own universe with its set of distinct planets and moons. No Man’s Sky, a game which prides itself for procedurally generating a whole universe, and Spore rely extensively on similar research.

Research Challenges

There are many research challenges involved. The first challenge is to generate the spherical geometry of the planet. It is as much of a challenge to choose the correct approach than to implement it. For this project, there are four approaches I will consider for generating a spherical mesh:

Four methods to draw a sphere, source.

The chosen method needs to meet the following criteria:

  1. Must to be efficient.
  2. Closer land must be drawn in more details whereas farther land must be drawn with far less details.
  3. Points must be (almost) equally distant from one another.

My initial attempt was to use ECP (latitude and longitude approach) which fails because points were not equally distant from one another for the terrain generation to work. For speed and simplicity, a ‘QuadCube’ seems to be the perfect candidate. The second challenge consists of searching for techniques for terrain generation. The algorithm I will most likely use is Simplex Noise, as it is an improved version of the popular Perlin Noise. I will write my own implementation in C++ and GLSL of the Simplex noise algorithm, based on Stefan Gustafson’s Simplex noise demystified paper. The third challenge is to wrap the generated terrain around the spherical mesh and end up with a prototype that can be tweaked by changing the variables falling under one of the three categories: terrain-related, planet-related and moon-related variables.

  • Terrain-related variables
    • Color palette
    • Type of texture
    • Height and density of the hills
  • Planet-related variables
    • Size
    • Position of the source of light (amount of daylight)
    • Speed of rotation around itself
  • Moon-related variables
    • Number of moons
    • Speed of rotation around itself
    • Speed of rotation around the planet
    • Distance between moon and planet

The model should be as flexible as possible to allow the creation of diverse planets. For example, the more variables available to tweak, the more combinations are possible and therefore the more diverse the generated planets become. The fourth challenge is to create benchmarks and compare performance with similar projects.

Overview of existing work

Procedural generation is a relatively old field that has its roots in the demoscene. The first game to use a seed to generate the world - Akalabeth: World of Doom - dates from 1980. However the field still remains largely unexplored. There already exists several implementations of the simplex noise algorithm. Here are a few:

Limitations of existing work

Many implementations of existing work were done with fixed-pipeline OpenGL (version 2 and prior). My implementation will be done using OpenGL 3. Additionally, I was not able to find any conducted research on writing an implementation that provides predefined themes (e.g. realistic vs. abstract terrain).

Potential directions and ideas for improvement

There are several directions for improvement. First, additional predefined themes can be added. Second, more variables can be added, like changing the color palette based on physical attributes such as the temperature (warm vs cold). Third, more game world entities can be added like vegetation (trees and bushes), water (lakes, seas and oceans), haze (clouds and fog) and cities (roads and buildings) that can all also be generated procedurally generated. Additionally, the textures for the terrain can be themselves procedurally generated. Finally, planets do not have to be generated on the fly. Meshes can be generated during production, hand-picked and saved for in-game use as prerendered assets.

Expected results and impact on the field

A report will be written as a guideline for generating planetary terrain, with an emphasis on performance and customizability. It will include an extensive description of the techniques used, important source code and benchmarks. The prototype will be pushed to my Github account and will include a wiki. The code will possibly be released under the MIT license. Finally, the targeted audience is independent game developers.