Terrain Texturing

Author: Thorsten Renk

Regional and procedural texturing

It’s perhaps not a big secret that the default Flightgear World Scenery does not look stunning everywhere in the world. Yet, with regional texturing in Flightgear 2.8 and easy to configure procedural texturing in the current development version 2.9, two techniques have arrived which have the potential to rapidly change this. But precisely what are these techniques?

Short of addons such as fgphotoscenery, Flightgear has never used aerial photographs for texturing. Instead, the terrain is described in terms of landclasses, and each landclass has an associated texture. Up to 2.8, these texture definitions were the same all over the world, Yet in reality, this is not true – cities in the US for instance tend to be organized in rectangular grid patterns which are completely uncommon in Europe, Irrigated crops in Asia are most likely rice terraces, whereas rice terraces are not a common sight in the US Mid-West. Regional texturing allows to define texturing schemes for specified geographical regions and allow to overcome these problems – European cities can now defined to look different from US cities.

Procedural texturing is an even more powerful technique. In the default rendering scheme, the terrain of a certain landclass is painted with a pre-defined texture, then the light is computed and this is what we see on the screen. Procedural texturing does not use a pre-defined texture, but computes the texture as part of the rendering process. This powerful technique allows textures to be sensitive to the environment and hence simulate wet or dusty terrain, to create the actual texture as a mixure of various overlay textures which change dependent on how steep the terrain is or to add snow cover with any density on the fly. Procedural texturing has been part of the shader effects in Flightgear 2.8, for instance in terms of the wind-dependent wave patterns of water, or the snowline settings, but in 2.9 it gained many additional options and most important is configurable without any knowledge of OpenGL rendering by just a few lines of xml code.

Procedural texturing is best illustrated pictorially – here is a scene (China Lake Naval Air Weapons Station (KNID), California) in default texturing. The visible terrain is mostly shrubland, and there is a pronounced tiling effect – the texture pattern is seen to repeat in the scene, leading to regular structures which become even more prominent from higher altitude.

The same scene in procedural texturing looks much more appealing – the random mixture of different base texture removes the tiling for good, and a thin dust effect creates the impression of dry terrain as appropriate for the near-desert location.

Unfortunately, procedural texturing does not come for free – computing textures on the fly creates a significant drain on framerate, thus procedural texturing is only suitable for modern graphics cards.

The structure of Flightgear Scenery

The combination of regional and procedural texturing is extremely powerful and allows to make dramatic improvements to the world scenery at the simple expense of few lines of xml code. Let’s look at an example location:

Canaima National Park in Venezuela is one of the world’s most fascinating mountain regions with table-mountains like Auyantepui towering over jungle terrain, featuring the world’s tallest waterfall, Angel Falls (3,287 ft). The scenery offers steep near-vertical cliffs hundreds of meters high, rugged and inaccessible plateaus atop the table mountains and lush tropical forest with winding reivers at their feet. The best place to access the park is Canaima airport (SVCN).

Yet, in the Flightgear default rendering scheme, Auyantepui is shown like this:

There is… something wrong here. In order to understand what goes wrong, let’s take a short look at the structure of the Flightgear scenery.

The basic ingredient of the scenery is the terrain mesh, containing the elevation data for all mesh points and the information what landclass the terrain between grid points is. The terrain mesh is created by a tool called TerraGear from public geodata. The output of this stage contains the altitude information of the terrain, and for instance the information that the terrain represents tropical forest (the so-called ‘landclass’).

Upon loading the terrain once it is used by Flightgear, the landclass is associated with a texture. At the same time, random objects such as buildings or trees are created and placed upon the terrain mesh where appropriate. Thus, the tropical forest landclass would at this step be associated with a forest texture and be populated with a large number of trees. At this stage, also shader effects are associated with a particular landclass, for instance water receives a reflection effect, whereas urban terrain may receive the urban shader effect.

In the last step, static (unique and shared) objects are added to the scene. These are objects which appear always at a given location, for instance airport terminals or special landmarks, and they are found in the Flightgear Scenery Database.

Armed with this knowledge, let’s analyze the above scene to find out what goes wrong: We can see that large parts of the table mountain get an agricultural texture. Visiting the scene with the ufo and using ctrl + alt + click (only in 2.9) on the offending terrain reveals that the mesh is here classified as ‘DryCrop’. This isn’t completely unreasonable, as the top of the table mountain is a rather barren grassland – but DryCrop becomes automatically associated with Europen-style agriculture textures – which look just plain silly in a place which in reality is utterly inaccessible, despite the valiant effort of the shader effect to change the agriculture to brown earth on steep slopes. Similarly, the nearby tropical forest is classified as ‘EvergreenForest’ (which is technically correct) – but EvergreenForest is associated with needle forest textures and needle trees.

Editing scenery texturing

There are various possibilities how this could be addressed. For instance, using TerraGear the landclasses in the scenery could be changed to something closer to reality. But to do this requires some learning, TerraGear is not a trivial tool. In this case, it is also unnecessary: The basic elevation mesh is in good order, the landclasses are not unreasonable, just the way textures and random objects are assigned to them is not working, and thus we need to change this.

The mapping of landclasses to textures and various other properties is controlled by a file called materials.xml. The regionalized version of it is found under $FGRoot/Materials/regions/materials.xml. In this file, for each landclass, a block of definitions exists. The idea is then to just copy the block for ‘DryCrop’ and edit the copy to contain an alternative definition valid for a particular geographical region, then change the texture to something more suitable. Plenty of nice textures already are in $FGRoot/Textures/Terrain/ and $FGRoot/Textures.high/Terrain/, so usually we don’t even need a new texture. While we’re at it, we might as well add two more lines to the etxture declaration specifying the overlay texture for procedural texturing. And that’s all it takes – next is EvergreenForest – we repeat the procedure and in addition change the tree texture from evergreen needle trees to tropical trees.

After just about an hour of editing materials.xml (the whole procedure is described in detail here), Canaima National Park looks like this:

Much better – isn’t it? Now all that’s missing is Angel Falls – we’re going to need a static model for this. The Particle System of Flightgear is going to be our friend here…

Canaima Sightseeing

After adding the model of Angel Falls using the ufo, Canaima National Park is ready for a sightseeing Flight (Flightgear 2.9 users can already enjoy it like this!) – once the landclass assignment is okay, procedural texturing takes care of the rest:

Steep cliffs and sheer drops flying over Auyantepui enroute to Angel Falls:

Table mountain tops reaching above the clouds:

Angel Falls seen from high altitude:

The barren top plateau of Auyantepui:

Tropical rainforest on return to Canaima airport:

Don’t wait for someone else to fix the terrain you want to explore – it’s easy, the tools are there and in many cases it’s more work to create a single model of a building than to make terrain texturing in a vast region look good!

6 Replies to “Terrain Texturing”

  1. Excellent work Thorsten, and excellent article too.

    Do you think is possible to use procedural textures, as a way to render create and export static textures for non powerfull PC users?.

    Thanks for you work.

    Michat.

    1. Static textures are very much a question of memory. Procedural texturing takes three texture sheets of ~500k, which expand to probably 2MB each when mipmapped and loaded into graphic memory and creates unique texture sheets for the whole scene.

      If you wouild like to have unique texture sheets for the above scene with static textures, you’d need with 50 km visibility about 2000 sheets of 2×2 km size. With 2 MB for each sheet, you’d end up with ~4 GB graphical memory requirement for terrain textures only to do the same job – which is in the league of current high-end graphics cards.

      So, basically we do procedural texturing because it’s, all in all, the cheapest way to get the scene rendered with unique textures everywhere.

        1. When users without high-end graphics cards do no longer complain that the framerate is low…

Comments are closed.