- Noise functions for global mesh
- Ancient Alien Civilization (AAC) algorithm realization
- New Postgis DB driver
Haskell PostGIS DB driver is now open source.
Haskell PostGIS DB driver is now open source.
On the planet Vitruvian Man there is only one mainland and it was made with the Ancient Alien Civilization method. In contrast to the planet Mandelbrot there is smaller grid step for the noise function and sea level slightly elevated.
The input polygon for the continent is the contour of the part of the widely known image.
As you may have already noticed among the planet examples a planet appeared in which the form of continents resemble letters. This is the result of application of the algorithm which I called the Ancient Alien Civilization method, as it is similar to the result of terraforming the planet by a developed ancient civilization. Of course, the form of the continents can be any with taking into account the minimum step of the planet basic heights grid.
The method is based on the good old noise functions, but supplemented by what can be called the imposition of a stencil. When we calculate the value of a noise function at a point, we also check the value of a specific function at this point (the stencil), which can have a value of either 0 or 1. If it has value 1 we store the value of the noise function, and if it is 0 we assign to the result a value of 0.
Thus, the stencil function defines the shape of the continents. In the example of Mandelbrot planet it is zero everywhere except the location of the letters. Such kind of map details have a relatively large scale, in the size of the continents. To get smaller details of the map (for example, craters) we must apply them already on local grid of rombs. But this is still in development.
The last picture is the unfolded view of the Mandelbrot planet continents.
Lets consider how you can use vector maps in games creating and what difficulties can be in this.
The game map of the world is an essential element of many video games of various genres. But even in the most advanced in the technical plan and popular games we see rather low detailed in-game maps. The map is especially important in games with a huge world, where the player need constantly determine his position in the world on the map. In many massive multiplayer online games the game map is a plain image of relief viewed from above and very uncomfortable. There is a natural and long overdue transition from image-maps to high detail vector maps.
On the other hand, if maps must depicture a large territory (even an entire planet) and/or has a high level of details, then the procedural generation of maps has no alternatives. Always keep in mind, that the generated map can always be supplemented with new details or it can be edited manually.
For many standealone and online games, there are map generators. But such generators are designed to produce small-detailed tile maps or each generated world is monotonous and does not correspond to the spherical geometry of a planet. While in massive multiplayer games, because of the difficulty of manually drawing large and detailed maps, game-devs prefer to use the same image of the world for unrelated gaming servers. And the emergence of another world is appeared as a very big event. With procedural generation new large and detailed worlds will become an ordinary event. Furthermore, it will be possible to make the games with a mechanism for generating or loading standardized in-game maps, and the action of different games can occur in the same world. As a universal map format, I propose to use the generally accepted data formats of modern GISs.
The terrain in many games is an integral part of them and the map of a game world is in interrelation with the terrain. During procedural generation of maps, one can build the map on the existing relief (as it is done in this project), consequently the relief and the map will be naturally related.
Output relief data of the project is represented by SRTM hgt data. SRTM data format represents a heightmap, while in the most games the relief is some polygonal mesh. Therefore, the first difficulty is the translation of a heightmap into a polygonal mesh. The most likely solution is to use a heightmap as a base mesh, which can be supplemented with details during the transition to a polygonal mesh. In this case, if details added are smaller than the size of small details of the original relief, then no map adjustment is required.
The presentation of data in the SRTM has a major drawback; it consists in the fact that the data density is changing with the latitude. But we have the entire accumulated arsenal of available tools for SRTM data format. The project internal binary representation of the data that depends on the division of the planet’s surface into rhombuses is nowhere else accepted, so currently I prefer SRTM as the output format.
Vector maps are not only provide an opportunity to highlight every detail of the world, but also the ability to change the world itself. And thus, the emergence of games in which the world itself is not only a background, but an active element of the game is possible.
I will give several possible examples which seem to me quite feasible today.
Since the maps are obtained with the help of GIS and are made for GISes, various manipulations with the map are permissible, as well as various representations of maps. What you can see on this site in the section of free maps is by no means the final appearance of maps. You can use different color representations and map types of your choice.
If you were interested in maps creation, then probably you are familiar with the hillshading type of earth maps. Such a representation of maps can be made with the maps obtained with the project, but in my opinion, satisfactory hillshading maps will be received only when higher resolution maps will be enabled in the project.
Also, by the means of gdal library, you can draw a contour height map (as in a topographic maps). But applying them to the SRTM data of an entire planet can require a very long run time. In my plans to make the height contours in the project itself. Obtained contour data will be included in the standard supply of the planet’s data.
When using the Web Merkator projection area near the poles are strongly stretched horizontally. But it is always possible to choose a different projection, in which the selected territory will have minimal distortion. As an option, it is possible to divide the world into pieces with less distortion (with a suitable projection) and display the map parts instead of the full planet map.
I think it’s time to explain the map generator design. This may shed light on the reasons for taken decisions and can explain the appearance of obtained results. Finally, I hope that the criticism of the approach will help to identify ways to improve the project.
First, the project is almost entirely written in Haskell. At the moment there are about 30,000 lines of Haskell code. The choice of language was due to the fact that it allows you to produce a productive compiled code, and the functional approach ensures a good structuring of this rather complex project.
(Earlier I had dealt with some hypostases of the functional programming, and therefore it was not so difficult for me to master the Haskell at a sufficient level.)
The whole process of planet map generating can be divided into two main stages: generating of planetary relief, and then, obtaining data and drawing the map over the existing terrain. Now we list these stages and their main divisions.
Next is a few comments on the mentioned stages.