Development History

Sometime in 2018, I discovered Scott Turner's work on Dragons Abound, which is his research & development into procedurally generated fantasy maps. At that time, my goal was to have a map generation solution that could determine world attributes such as the land & sea regions, terrain elevation, biomes and a river network. Another experiment at that time was the cascading solution of the world map, which allowed it to have different levels of detail.

Our prior work during 2020/2021 was a revision to the map generation solution but with the added visual detail in tiny coloured cubes, so that the world map can be rendered in real-time. At that time, the map generation solution was confined to 256x256 points, with small continents formed using a simulation of tectonic accretion. There was also a river network done using a modified A* search solution and a geometry tiling system for land, water and rivers.

A number of outstanding issues remained with the prior map generation solution. The size of the map uses only 256x256 points and 2048 voronoi cells, which constrains the regional scope of each land biome type. The continents are packed with different land biomes with a small regional scope, that might result in insufficient space for settlement placement without getting too close to one another.

The prior island generation system did not produce beaches and the coastline was an abrupt discontinuity between land and seawater. There was no latitude variation for its land and wetland biomes and lakes do not occur on the large-sized islands. The colour variation of the biomes on the islands is also limited to those that are related to greenery.

The prior map generation solution also did not fill the impassable border with seawater, showing the end of the world map with the void of the world as there was nothing rendered there. And there was little possibility that two islands could be combined together by connecting neighbouring voronoi cells. There was, however, a volcanic biome found on one of them.

The precomputed dataset for the Centroidal Voronoi Tessellation required the map generation solution to do polygonal scan-line rendering in order to get the points that the voronoi cell occupies on the map. This was inefficient because the point dataset could have been precomputed.

The precomputed geometry tiles had been rather unoptimised, with a lot of unwanted hidden geometry that should not have been precomputed. That contributed to a prior heavy usage of system memory while being implemented on iOS.

Additionally, the prior set of geometry tiles had only accounted for one differing neighbour material, resulting in numerous sharp protrusions in areas where there are more than one different neighbouring biome meeting at a boundary.

Motivations

Our present motivation is to rework the prior map generation solution with a number of major changes in order to develop a much better foundation before adding settlements and other objects onto the map. Instead of trying to rework the entire world map generation solution in one attempt, the entire solution will be broken up into smaller iterations. As such, we will defer the rework on the continental tectonics, rivers and map cascading systems to a later project. In this manner, we will be able to focus on developing a much more fulfilling island generation solution that will have better variation and be much more optimised and efficient.

Furthermore, the present map generation solution produces an acceptable visual quality that is colourful and detailed even without any lighting. We can keep this visual quality for future projects that produce only flat world maps, while adding lighting and soft shadows for world maps that include objects such as settlement buildings on top of the map layer.

One of the problems with existing voxel-based world maps is that they can lose meaningfulness if there are too many colourful cubes clogging up the whole map scene. Such is the case for Cube World, when the camera view zooms out to show a wide view of the world map. It becomes difficult to discern particular regions on the map. We would like to avoid this problem.

Our concept prototype using Magicavoxel also showed that there exists a possibility of generating a world map filled with terrain and settlement objects, without the clutter of many small coloured cubes all over the map. We use this concept as a guide to reaching our eventual goal of generating fantasy maps using tiny cubes.

However, we will need to add a real-time global illumination (GI) solution in order to light up the scene, showing the inter-diffuse reflections and soft shadows. One such GI solution that can be feasibly implemented is Precomputed Radiance Transfer using Spherical Harmonics as the encoding medium.

Solution Changes

Previously we tried to have three continents on a 256x256 point map. For this project, the number of large-sized islands is between two to four within the same map dimension. The dimension of each large-sized island is also much bigger than the largest island in our prior solution, although they remain smaller than the continent. Hence, our goal is to provide more space for the current island generation solution.

The variation of the land biomes on the islands has been expanded and is also partially determined by the latitude region in which the islands are located. The islands in the polar region have different land biomes compared to those in the tropical region.

All the islands are assumed to have a continuous coastline of beaches, with different types of coastline colours, such as grey for rocky beaches, beige for fine sandy beaches and khaki for tundra coastlines.

The rework for the continent generation solution will be deferred to a later project that uses multiple 256x256 point maps. The volcanic biome will be deferred to a later implementation as well.

The impassable border of the scene has also been filled with seawater and the islands are only generated within the center map region. In order to fill up the whole scene, additional border maps are placed around the center map and they contain only seawater regions.

The current solution also implements an overlapping system which spreads point data across the border of the center map, which will be received by the nearest voronoi cells on the border maps. This allows the present seawater type to overlap nicely across onto the neighbouring map without an abrupt end at the border.

There are different types of lakes that can be found on the large-sized islands, such as frozen lakes (light-cyan), freshwater lakes (light-blue), brackish-water lakes (light-brown), algae-water lakes (dull-green) and saltwater lakes (bright reddish-pink). The lakes are also partially determined by the latitude region, in addition to the salinity of the lake water.

Sometimes the solution may generate large islands too close to one another and they could combine and form an elongated island by connecting neighbouring voronoi cells. This allows us to have rarities that are not determined by a randomised number, but rather from a confluence of factors, such as the location and accumulation of nearby voronoi cells during the formation of these large-sized islands.

The Centroidal Voronoi Tessellation solution that the current map generation uses has been made more efficient by precomputing the point locations that each voronoi cell can occupy on the map. Instead of storing the point data in individual locations, the data is stored in a range format for each row of points that the voronoi cell occupies on the map.

Instead of building for iOS & Metal as we had been doing previously, a portion of the solution has been ported to use javascript and webGL2 from three.js. The precomputed geometry tiles had been scrutinised for memory optimisation and unwanted geometry had been removed, resulting in a much smaller footprint on the disk and savings in system memory.

The current set of geometry tiles supports one to four differing neighbouring materials, allowing for a more natural jagged boundary without too many prior sharp protrusions that result from only having one neighbouring material.

We will discuss the development techniques that we use for this project in our next article.

References

Dragons Abound (by Scott Turner) https://heredragonsabound.blogspot.com/

Our last development blog post: https://www.littlecubevalley.com/devblog

Project Preview

To move the camera around the scene, hold down the left mouse button within the display panel and away from the center. To rotate the camera view, press 'C'.