This is the last blog post in this year, obviously)) A month ago I started a new experiment – splitting detail textures into two sets:

Material (soil) textures, which are used at a centimeter-scale levels. These are sand, pebbles, grass etc textures. Sample textures, which are used at a kilometer-scale levels. These are terrain close-up textures, made from a real satellite images of Earth, Mars and other planets.

The first set of textures are almost the same as described in my previous posts. These textures are applied at render time, ie by the planet rendering shader. In order to increase FPS, I limited texturing by just 2 samples per pixel, not 3 like before. So now there just 2 texture layers: “base” texture, for example large chunks of rock, and “modulate” texture, for example close-up rock texture with small pits and spots. Variation at a larger scale (dozens of meters) is achieved by combining 4 such “materials”, controlled by the splat map texture.

The second set of textures replaces the old 0.980 texture atlas. But this time it is not rocks/pebbles/grass textures, but rather satellite/aero photos of real planets. It looks pretty promising, despite on the fact that those ridges and valleys are just a textures, they doesn’t follow a real terrain elevation (adding an elevation samples is the next task):

These textures are applied at generation time, ie by the terrain generator shader. So blending, tile pattern reduction and other algorithms can be much more complex than in the planet rendering shader, because it doesn’t affect FPS, just increases the terrain generation time. Currently this system also uses 2 layers of textures, which are blends together at different scales.

There is a new generation stage – the splat map generator shader. It tries to assign the soil detail texture based on the color of the planet surface at this point (taken from the terrain patch texture). This is controlled by a special material script, where soil “materials” are described: used textures, scaling/blending options, and the target color. For example, grass material uses grass close-up texture and a large scale color variation textures, and have a green target color. The sand material uses a dunes texture, modulated by as small-scale sand grains texture, and has a yellow target color. The splat map generator shader then takes the previously generated color texture of a surface patch, looking at the color of each pixel, and tries to determine, which material is suitable for it. For example, green pixels are likely to be grass, yellow – sand, white – snow and so on. The list of allowed materials is controlled by the biome config file of a planet, so lifeless desert worlds will not have grass material, even if there are some green areas. Assignment of materials is also controlled by the surface slope, biome id and other parameters. The shader then takes 4 most suitable materials and generates 2 splat textures – the material id and material weights. These splat textures are then used by the planet rendering shader to select and blend 4 materials based on their weights.

The most exciting thing about this system is that it works “from the box” on real planets – Earth, Moon, Mars. Just configure the biome config file for them (there is ability to specify an exclusive config file for a real planet), and create some unique material config files. So at the ground level, real planets now looks great. They only lacks the mid-scale features, which is a goal for the next experiments with procedural terrain refinement.

I’m still have to do many things, some approaches are highly experimental. For example, using a splat maps in the rendering shader is not straight-forward, because if material id changes in adjacent texels in the splat map, this result in seams on the rendered image. So I’ve implemented a “manual” interpolation code, but it requires additional computing power and does not fixed all seams. Recently I’ve tried to remove the splat map generation pass, and add a color-analysing code into the planet rendering shader. Surprisingly, it almost as fast as the code with splat maps with manual interpolation, as long as planet doesn’t have too much unique materials (16 or less). So there are many areas of improvement. I expecting that work on terrain will last another few months. Especially if implementing a procedural terrain refinement for Solar system planets. The “bug reports” about flat and blurry textures on Earth are very annoying.

Also, a large time-consuming thing is creating biome/palette and material presets for all types of planets. Here I rely on the beta testers help – once the new terrain system is complete, I’ll release the beta build for them, and write a manual about creating the corresponding preset files.

Happy New Year!

Discuss this post on the forum.