Table of Contents
This page is intended to answer a frequently asked question regarding terrain textures:
There are several ways to display grass in 3D renderers:
The most realistic way to display grass in a 3D rendering environment is to use 3D geometry. That is to say, use meshes and/or impostors with their own leafy texture. I'd go so far as to say that all modern 3D game engines support some manner of support for grass rendering using 3D geometry.
Note that this approach does not require a particularly high-resolution texture. The underlying terrain should be largely obscured by the grass/foliage, so a viewer can't really see whether the terrain texture is low or high resolution.
A relatively cheap way to display grass is to modulate the terrain texture during rendering (i.e. on the GPU) with a greyscale 'detail map' image of grass blades. This basically splits the ground texture into two parts:
This is demonstrated in the image below, which is a composite of two screenshots from Sapphire with the detail map turned off and on. In the left of the image, you can see just the underlying low-resolution colour texture. In the right of the image, you can see the huge improvement in apparent detail provided by the detail map overlay.
The great thing about detail maps are that they're cheap. GPUs are very fast at blending textures, and the detail map doesn't consume much memory because the GPU tiles and repeats it over the terrain surface. Thus, the use of detail maps is very common in game engines.
The main down-side to detail maps is that the same detail image is used across the entire terrain surface. Thus, for example, you can't use a (single) detail map to provide both highly detailed grass and highly detailed rocks. In the screenshot above, you can see that Sapphire uses a generic-looking 'dirt' detail map that was designed to look OK on grass, rock, sand, snow and all other land types.
In texture splatting, the texture for each fragment of terrain is blended together per-frame by the GPU from a set of small base textures (e.g. grass, rock, sand, etc.), using a set of masking images or 'alpha maps'. As with detail maps (discussed above), these base textures are tiled and repeated over the terrain surface. Thus, the apparent detail achieved by texture splatting depends on the area covered by each repeating tile, which can be as small as you like, and thus as highly detailed as you like. This approach is used by most modern game engines for rendering terrain.
The nifty thing about texture splatting is that the complete terrain texture is never generated. The GPU only generates the tiny amount of texture required to render each fragment of terrain. This means that the texture memory requirements for texture splatting are very modest, even for extremely high apparent detail levels.
The fourth method I'll discuss is to simply bake the grass blade texture image onto the terrain texture. At a superficial level, this seems to be the easiest solution, since:
Unfortunately, life is not so simple.
Let's start by considering the physical size of your terrain map. For a typical first-person shooter (FPS) style map, you might have it cover a square kilometre or so. This gives you a few minutes of running time from one side to the other.
The next thing to consider is the size of a blade of grass. Depending on local climate, you might say that a blade of grass is 5 millimetres wide.
Finally, let us consider what limits the smallest size of an object that you can display in a texture image. I hope the answer is obvious; you cannot display a feature that is smaller than one pixel in size 1).
If we're going to pre-calculate one large texture image for the entire terrain surface, this means that our texture has to cover out chosen area (1000m x 1000m) with a resolution of 0.005m x 0.005m per pixel. If yo do the math, that requires forty trillion pixels, or put another way, an image that is 200,000 x 200,000 pixels in size. Not many game engines (nor disk-drives) can handle an image that large.
This assumes of course that the resolution of your texture is constant across your map, as it is with most currently available game engines.
Perhaps the largest pre-calculated textures used in a published game to date were those of Enemy Territory: Quake Wars, which were something like 32,768×32,768 pixels in size. That's a whole lot of texture. In fact, it's called a MegaTexture.
L3DT does indeed support megatextures; it can generate textures up to 2 million by 2 million pixels in size.
Megatextures are, by their very nature, huge and highly detailed. Indeed, they are substantially more detailed than the terrain geometry they cover. The sequence of images below show the effect of increasing the size of the texture map for a given heightfield size, as expressed as the texture to heightfield ratio (TX/HF ratio).
The first image is a standard texture that is, if I recall correctly, a very quick and nasty 256 x 256 pixel texture on a 256 x 256 pixel heightfield, giving a TX/HF ratio of 1. The next image down is a 512×512 pixel texture on the same 256×256 pixel hightfield, which therefore has a TX/HF ratio of 2. This continues down to a 8192×8192 pixel texture on the 256×256 pixel heightfield, which has a TX/HF ratio of 32 (this is L3DT's current limit for TX/HF). Note how at each increase in TX/HF ratio, the visible detail of the terrain texture drastically improves.
The take-home message here is that if you want very high detail and you want to use a pre-calculated texture, you need to generate a huge texture image. There is no substitute for pixel density!
If you have any questions, or dispute any of the assertions on this page, please reply to this forum thread.
1) By this I mean display a resolvable a feature, in the optical sense.
Except where otherwise noted, content on this wiki is licensed under the following license:CC Attribution-Share Alike 3.0 Unported