L3DT users' wiki
Large 3D terrain generator

 

This is an old revision of the document!


Rendering grass and highly detailed terrain textures

This page is intended to answer a frequently asked question regarding terrain textures:

Q: How do I increase the texture detail so that blades of grass are visible?

There are several ways to display grass in 3D renderers:

1. Use 3D geometry

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.

The example below was provided by JohnJ using his PagedGeometry module for the Ogre3D engine, with a terrain map generated in L3DT:

www.bundysoft.com_coppermine_albums_userpics_tropicvista2.jpg

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.

2. Use a detail map

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:

  1. A relatively low-resolution terrain texture image to provide the terrain colour, and;
  2. A higher-resolution repeating image to impart the detail of the grass.

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.

Detail map off Detail map on

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.

3. Use texture splatting

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 example screenshot below was provided by sergeymak in this forum thread using his MegaTerrain engine, which performs texture splatting using masks generated from L3DT's attributes map:

:tutorials:l3dt:tx_res:megaterrain.png

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.

4. Use megatextures

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:

  1. L3DT only has to blend together some textures with grass blades on it (which is trivial), and;
  2. The 3D renderer only has to drape the texture over the terrain geometry (which is also trivial).

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.

Terrain size: 1000m (side length)

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.

Grass blade size: 0.005m (side length)

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.

Resolution considerations for megatextures

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.

TX/HF ratio Image
1x http://www.bundysoft.com/L3DT/gallery/v26/10Sept08/1xRes.jpg
2x http://www.bundysoft.com/L3DT/gallery/v26/10Sept08/2xRes.jpg
4x http://www.bundysoft.com/L3DT/gallery/v26/10Sept08/4xRes.jpg
8x http://www.bundysoft.com/L3DT/gallery/v26/10Sept08/8xRes.jpg
16x http://www.bundysoft.com/L3DT/gallery/v26/10Sept08/16xRes.jpg
32x http://www.bundysoft.com/L3DT/gallery/v26/10Sept08/32xRes.jpg

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!

Questions or objections?

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.
 
tutorials/l3dt/tx_res.1377130165.txt.gz · Last modified: 2017/08/31 05:10 (external edit)
 
Except where otherwise noted, content on this wiki is licensed under the following license:CC Attribution-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki