Many people have been asking me how the terrain texturing is implemented, so I'll make a special dev journal about it.

Sub-tiling

The whole technique is based on sub-tiling. The idea is to create a texture pack that contains N images ( also called layers or tiles ), for example for grass, rock, snow, etc..

Let's say that each image is 512x512. You can pack 4x4 = 16 of them in a single 2048x2048. Here is an example of a pack with 13 tiles ( the top-right 3 are unused and stay black ):



Mipmapping the texture pack

Each image / tile was originally seamless: its right pixels column matches it left, and its top matches its bottom. This constraint must be enforced when you're generating mipmaps. The standard way of generating mipmaps ( by downsampling and applying a box filter ) doesn't work anymore, so you must construct the mipmaps chain yourself, and copy the border columns/rows so that it's seamless for all levels.

When you're generating the mipmaps chain, you will arrive at a point where each tile is 1x1 pixel in the pack ( so the whole pack will be 4x4 pixels ). Of course, from there, there is no way to complete the mipmaps chain in a coherent way. But it doesn't matter, because in the pixel shader, you can specific a maximum lod level when samplying the mipmap. So you can complete it by downsampling with a box filter, or fill garbage; it doesn't really matter.

Texture ID lookup

To each vertex of the terrain is associated a slope and altitude. The slope is the dot product between the up vector and the vertex normal and normalized to [0-1]. The altitude is normalized to [0-1].

On the cpu, a lookup table is generated. Each layer / tile has a set of constraints ( for example, grass must only grow when the slope is lower than 20? and the altitude is between 50m and 3000m ). There are many ways to create this table, but it's beyond the point of this article. For our use, it is sufficient to know that the lookup table indexes the dot-product of the slope on the horizontal / U axis, and the altitude on the vertical / V axis.

The lookup table ( LUT ) is a RGBA texture, but at the moment I'm only using the red channel. It contains the ID of the layer / tile for the corresponding slope / altitude. Here's an example:



Once the texture pack and the LUT are uploaded to the gpu, the shader is ready to do its job. The first step is easy:

vec4 terrainType = texture2D(terrainLUT, vec2(slope, altitude));

.. and we get in terrainType.x the ID of the tile (0-15) we need to use for the current pixel.

Here's the result in 3D. Since the ID is a small value (0-15), I have multiplied it by 16 to see it better in grayscale:



Getting the mipmap level

So, for each pixel you've got an UV to sample the tile. The problem is that you can't sample the pack directly, as it contains many tiles. You need to sample the tile within the pack, but with mipmapping and wrapping. How to do that ?

The first natural idea is to perform those two operations in the shader:

u = fract(u)v = fract(v)u = tile_offset.x + u * 0.25v = tile_offset.y + v * 0.25

( remember that there are 4x4 tiles in the pack. Since UVs are always normalized, each tile is 1/4 th of the pack, hence the 0.25 ).

This doesn't work with mipmapping, because the hardware uses the 2x2 neighbooring pixels to determine the mipmap level. The fract() instructions kill the coherency between the tiles, and 1-pixel-width seams appear (which are viewer dependent, so extremely visible and annoying).

The solution is to calculate the mipmap level manually. Here is the function I'm using to do that:

/// This function evaluates the mipmap LOD level for a 2D texture using the given texture coordinates/// and texture size (in pixels)float mipmapLevel(vec2 uv, vec2 textureSize){    vec2 dx = dFdx(uv * textureSize.x);    vec2 dy = dFdy(uv * textureSize.y);    float d = max(dot(dx, dx), dot(dy, dy));    return 0.5 * log2(d);}

Note that it makes use of the dFdx/dFdy instructions ( also called ddx/ddy ), the derivative of the input function. This pretty much ups the system requirements to a shader model 3.0+ video card.

This function must be called with a texture size that matches the size of the tile. So if the pack is 2048x2048 and each tile is 512x512, you must use a textureSize of 512.

Once you have the lod level, clamp it to the max mipmap level, ie. the 4x4 one.

Sampling the sub-tile with wrapping

The next problem is that the lod level isn't an integer, but a float. So this means that the current pixel can be in a transition between 2 mipmaps. So when calculating the UVs inside the pack to sample the pixel, it has to be taken into account. There's a bit of "magic" here, but I have experimentally found an acceptable solution. The complete code for sampling a pixel of a tile within a pack is the following:

/// This function samples a texture with tiling and mipmapping from within a texture pack of the given/// attributes/// - tex is the texture pack from which to sample a tile/// - uv are the texture coordinates of the pixel *inside the tile*/// - tile are the coordinates of the tile within the pack (ex.: 2, 1)/// - packTexFactors are some constants to perform the mipmapping and tiling/// Texture pack factors:/// - inverse of the number of horizontal tiles (ex.: 4 tiles -> 0.25)/// - inverse of the number of vertical tiles (ex.: 2 tiles -> 0.5)/// - size of a tile in pixels (ex.: 1024)/// - amount of bits representing the power-of-2 of the size of a tile (ex.: a 1024 tile is 10 bits).vec4 sampleTexturePackMipWrapped(const in sampler2D tex, in vec2 uv, const in vec2 tile,	const in vec4 packTexFactors){ 	/// estimate mipmap/LOD level	float lod = mipmapLevel(uv, vec2(packTexFactors.z));	lod = clamp(lod, 0.0, packTexFactors.w);	/// get width/height of the whole pack texture for the current lod level	float size = pow(2.0, packTexFactors.w - lod);	float sizex = size / packTexFactors.x; // width in pixels	float sizey = size / packTexFactors.y; // height in pixels	/// perform tiling	uv = fract(uv);	/// tweak pixels for correct bilinear filtering, and add offset for the wanted tile	uv.x = uv.x * ((sizex * packTexFactors.x - 1.0) / sizex) + 0.5 / sizex + packTexFactors.x * tile.x;	uv.y = uv.y * ((sizey * packTexFactors.y - 1.0) / sizey) + 0.5 / sizey + packTexFactors.y * tile.y;    return(texture2DLod(tex, uv, lod));}

This function is more or less around 25 arithmetic instructions.

Results

The final shader code looks like this:

const int nbTiles = int(1.0 / diffPackFactors.x);vec3 uvw0 = calculateTexturePackMipWrapped(uv, diffPackFactors);vec4 terrainType = texture2D(terrainLUT, vec2(slope, altitude));int id0 = int(terrainType.x * 256.0);vec2 offset0 = vec2(mod(id0, nbTiles), id0 / nbTiles);diffuse = texture2DLod(diffusePack, uvw0.xy + diffPackFactors.xy * offset0, uvw0.z);

And here is the final image:



With lighting, shadowing, other effects:



On the importance of noise

The slope and altitude should be modified with many octaves of 2D noise to look more natural. I use a FbM 2D texture that I sample 10 times, with varying frequencies. 10 texture samples sound a lot, but remember that it's for a whole planet: it must look good both at high altitudes, at low altitudes and at ground level. 10 is the minimum I've found to get "acceptable" results.

Without noise, transitions between layers of different altitutes or slope look really bad: