Advanced Terrain Texture Splatting

In this article I will explain a texture splatting algorithm which allows you to create more natural terrain. This algorithm may be used in shaders of 3D games as well as in 2D games.

One of the most common ways of terrain texturing is blending multiple tiled layers. Each layer has an opacity map which defines the extent of texture presence on the terrain. The method works by applying an opacity map to the higher levels, revealing the layers underneath where the opacity map is partially or completely transparent. Opacity map is measured in percentage. Of course on each point of a terrain the sum of opacities of all layers makes one-hundred percent as the terrain can't be transparent. Instead of tile textures, the opacity map stretches entirely on all terrain and therefore has quite a low level of detail.

Now we will pass to the most interesting part — algorithms of blending of textures. For simplicity and obviousness our terrain will consist of sand and large cobble-stones.

Simplest way of blending is to multiply texture color with opacity and then sum results.

Such a technique is used in Unity3D in the standard terrain editor. As you can see, the transition is smooth but unnatural. Stones look evenly soiled by sand, but in the real world it doesn't happen like that. Sand doesn't stick to stones, instead it falls down and fills cracks between them, leaving the tops of stones pure.

Let's try to simulate this behavior in Excel plots. As we want sand to be "fallen down" between cobble-stones, for each texture we need the depth map. In this example we consider the depth map is generated from grayscaled image and stored in the alpha channel of a texture. In Unity3D it can be done in the texture inspector by setting the flag "Alpha From Grayscale".

First of all we will consider the simplified model of depth map of sand and stones.

The blue line on the plot symbolizes the depth map of sand and red is cobble-stones. Notice that tops of stones lie higher than sand level. Considering this fact, we will try to draw pixels of that texture which is above.

At the expense of summation less transparent texture will be higher than usual.

So we have a more natural transition from sand to stones. As you can see, grains of sand start filling cracks between cobble-stones, gradually hiding them. But as calculations happens pixel-by-pixel, artifacts begin to appear on the border between textures. To get a smooth result we will take several pixels in depth instead of one and blend them.

In the code above we at first get part of a ground seen at a certain depth.

And then we normalize it to get new opacities.

As a result we found the algorithm of textures blending, which allows us to reach close to a natural terrain image.

In summary I want to explain what this algorithm was developed for and how we use it.

The shader was developed for turn-based strategic indie game Steam Squad. As engine and developing platform we use Unity3D. And as the Unity IDE is extremely flexible, we made our own level designer extension. In general the level designer is a simplified Unity3D terrain editor with some features of Titan Quest Editor.

When you paint the texture on a terrain there is a recalculation of the opacity map corresponding to this texture. And as the sum of all opacities has to make 100%, the editor automatically normalizes opacity maps of other layers.

I think many people have, the issue is the draw call and the load times; which leads me to my question.

Doesnt the pixel shader run slower and cause considerable lag on a procedurally generated terrain setup?

This setup would work on solid, never changing terrain, but I think it would cause serious issues with terrain that was to change on a constant or semi constant basis. Each modification of the land would require another draw call, would it not?

Also, with our system we have been looking at doing this but we have 3 textures maps ( normal, specular, color ). Each one of these would need a new sample, this means 3 * 3 = 9 samples. We would have to blend this with another texture ( for the edges of the blocks/regions ) making a total of 18 samples.... is this correct?

Shader behaves exactly like default one. Of course, it has more math operations, but delay is absolutely insignificant. In the my implementation of shader I can blend 9 textures: 4 color maps + 4 normal maps + noise map. And with some math magic I still fit in SM2.0 limitations.

Also with some storage magic the changing of texture transparency isn't more difficult than moving point of a mesh. I can change it in realtime, but changing of set of textures is still expensive operation.

Sorry but I can't show you all sources because the shader is part of commercial project.

You could get the same result by prefiltering the alpha map, avoiding all but one sample in the pixel shader. And if you employ some kind of relief shader, I suggest using the height map instead.

I employed this method to much success, but I didn't use a hard comparision but instead used a simple smoothstep() to blend between to two. Also works nice, but had the downside that the order of sequence is now important. It's always "one on top of the other". Which was fine for me as my terrain blending put one material per pass.