3D Game Programming All in One (Course Technology PTR Game Development Series)

There are basically two approaches that 3D game engines use to model terrain in a 3D world. In both cases 3D polygon models represent terrains.

In the external method we include the terrain as just another object in the game world. This method offers much freedom of manipulation. You can rotate the terrain model, skew it, and otherwise subject it to all manner of indignities. All 3D engines support this approach. While flexible, it is usually an inefficient way to render complex large terrains.

The second approach is the internal method, where terrain is rendered by special code in the game engine often called a Terrain Manager. Using the Terrain Manager approach allows game engine programmers to apply specific memory and performance optimizations to the terrain object, because they can discard unnecessary functions that would be available to general-purpose objects. Because of this, Terrain Manager terrains can sometimes be made larger and more complex than those created using other approaches.

Most 3D engines, like Torque, that use a Terrain Manager also provide terrain generation, manipulation, and editing tools that we can use to create our own terrains. Usually importing height maps is available for terrain generation. Some engines, like Torque, have built-in Terrain Editors that allow the game developer to directly manipulate terrain polygons, within constraints, to create the desired hills, valleys, mountains, and canyons.

Height Maps

Figure 12.2 depicts a height map. As you can see, it's a grayscale image. The 2D coordinates of the height-map image map directly to surface coordinates in the game world. The brightness off each of the pixels in the image represents the altitude at that pixel's location—the brighter the pixel, the higher the elevation. Usually we use an 8-bit per pixel format, which means that 256 discrete elevations can be represented.

Figure 12.2: A terrain height map.

The concept is an elegant one and not difficult to grasp. If you are familiar with viewing topographic charts and maps, you'll find that height maps have a familiar flavor to them, even though the contour lines are missing. One of the deficiencies of height maps is the resolution (as you can see in Figure 12.2). To represent a geographic locale that is 1 kilometer square, a height map that represents 1 square meter as a pixel needs 1,000 pixels per side, for a total of 1 million pixels—big, but not too large. If I want to increase the terrain area to cover 16 square kilometers (4 meters per side), then I need to store 16 million pixels. At 8 bits per pixel, that equals about 16MB of data. If we want to model the terrain for an area that is 10 kilometers per side, we are looking at 100MB of storage!

We can, of course, reduce the terrain resolution— let's say, have a pixel equal 4 square meters in the game world. This would chop those 100MB back to 6.25MB. However, that gain is offset by the fact that our terrain will now be blockier and less realistic.

Figure 12.3 shows a terrain model generated from the height map shown in Figure 12.2. In this case MilkShape was used to import the height map and create the terrain object.

Figure 12.3: A terrain created from a height map.

Terrain Cover

In the simplest sense, terrain cover refers to all the stuff that you find on the ground, including:

Obviously this is not a comprehensive list, but it does demonstrate the point.

We represent the terrain cover with textures. Our options for creating these textures are much like those we considered when we created textures for structures in Chapter 11— and the factors that dictate which way to choose are also similar. It boils down to the terrain characteristics in the game that matter to you.

We can also mix terrain cover textures in adjacent areas to portray a particular locale. It's a good idea to develop your own library of generic terrain cover for use in various situations.

Figure 12.4 illustrates some of the possible varieties of terrain cover. From left to right in the top row you can see grass, sand, and an intermixed sand and grass texture. In the bottom row from left to right are dirt, a muddy track, and eroded wet sand.

Figure 12.4: Some example terrain textures.

Tiling

Unless you are going to create specific terrain cover textures for every square inch of terrain, you will end up tiling your terrain cover at some point. All the issues brought up with tiling in other contexts apply here, such as matching texture edges to get seamless transitions and ensuring lighting in the textures is both appropriate and uniform. Additionally, you should ensure that there are no patterns or marks in the texture that will stand out too much when the texture is repeated.

In Figure 12.5 you can see a repeating light pattern that tends to overpower the otherwise pleasing and pastoral scene. (Okay, okay, it would be pastoral if a storm wasn't brewing beyond the, um…Mountains of Evil in the distance. But besides that…)

Figure 12.5: A terrain with tiling artifacts.

The culprit in this case is the grass texture used, which is shown in Figure 12.6.

Figure 12.6: A texture with an undesirable feature.

Notice the area of lighter grass, which is quite noticeably different from the rest of the image. When repeated over and over across large swaths of terrain, that feature detracts from the intended overall effect. We can enhance the image to minimize the problem, perhaps with something like that shown in Figure 12.7.

Figure 12.7: A texture without the undesirable feature.

The result is dramatic and the difference is quite obvious, as you can see in Figure 12.8. Now, I confess that the texture could be better, but you have to admit that it is light-years ahead of the first version, shown in Figures 12.5 and 12.6.

Figure 12.8: The terrain with improved tiled texture.

Категории