Howto:Regional texturing: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 85: Line 85:


Note that using material definitions it is possible to merge different landclasses - in the above example triangles classified as 'Dirt' and 'Rock' will look and feel the same - but making two separate definitions instead, they could also be made to look differently. Again, a single landclass can not be made two different materials in the same region - later definitions will overwrite earlier ones.
Note that using material definitions it is possible to merge different landclasses - in the above example triangles classified as 'Dirt' and 'Rock' will look and feel the same - but making two separate definitions instead, they could also be made to look differently. Again, a single landclass can not be made two different materials in the same region - later definitions will overwrite earlier ones.
=== Basic workflow ===
To make a regional texture definition for a region then, you need to
* define a region by creating a file with a name, area and condition header
* include this file in materials.xml
* fill it with individual material definitions which are supposed to apply to the region
For the latter task, you may or may not have to
* acquire suitable textures for the region
* configure the procedural texturing parameters to generate good composite textures
* assign random trees, buildings, materials, lights,...
* assign surface properties

Revision as of 06:02, 9 April 2016

WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.

The Flightgear terrain is created in a largely automated process from a large amount of geodata. The outcome may not necessarily always look like a region appears in reality. Regional texturing is one of the most powerful tools available to improve the visuals and get a result much closer to reality.

Background

Terrain data structures

Tnternally, the terrain is a dense mesh of triangles which determine the elevation at each given point. However, the mesh also encodes what a patch of terrain is supposed to represent by assigning a so-called landclass to a triangle. Landclasses are a concept that is directly inherited from geo databases like CORINE. For instance, the database may tell that a certain patch of terrain is 'Shrubcover'. This information is stored with the terrain mesh.

Flightgear then uses it in-sim in several ways: First, the landclass of a triangle determines how it appears, i.e. what texture and/or effect are assigned. Second, it also determines FDM-relevant properties, for instance whether it will yield when you try to land on it (for instance water), whether you can roll across it, how bumpy rolling will be, and so on. The Advanced Weather system uses the landclass to determine the likelihood of convective cloud formation when the sun heats the terrain. Finally, also the distribution of random overlay objects (such as the density of lights at night or the number of trees or buildings appearing) is also determined by the landclass.

A separate layer for the terrain are static objects which are placed on definite positions onto the mesh by other means - for their placement, no landclass information is used and while they can be placed 'onto' the mesh automatically, they can also be placed to absolute altitudes.

Regional texturing specifically changes the appearance of a landclass and also the placement of overlay objects - it is not a technique capable of altering the outlines of landclasses in the mesh. In other words, using the technique you can make an existing patch of shrubland look more realistic, but you can not change part of a lake that has the wrong shape to be shrubland.

Control files

The central file responsible for the assignment of textures etc. to landclasses is /Materials/regions/materials.xml (for historical reasons, there are two alternative schemes under /Materials/default/materials.xml and /Materials/dds/materials.xml which are not supposed to be modified by regional definitions). They can be selected in-sim in the rendering dialog.

materials.xml largely serves as an index to include the actual regional definitions. However, hierarchy is important and needs to be considered: Later valid definitions always override earlier definitions. So for instance in texturing Honolulu, Hawaii, first global-summer.xml is considered (which is the world-wide default for summer textures), then the content of hawaii.xml overwrites the global definitions and finally the content of oahu.xml overwrites part of the Hawaii-specific definitions. The wrong order of files can lead to definitions not being used.

Each specific region file has to contain a name, at least one (possible more) area definitions and may contain a condition. The header of the Hawaii region for instance is

  <name>Hawaii</name>
  <area>
    <lon1>-179.0</lon1>
    <lon2>-154.0</lon2>
    <lat1>18.8</lat1>
    <lat2>28.5</lat2>
  </area>

  <condition>
    <equals>
      <property>sim/startup/season</property>
      <value>summer</value>
    </equals>
  </condition>

The area tags define rectangles in coordinates - if FG requests a scenery tile to load, and the coordinates of the tile are within the area defined and the condition is met, the landclass definitions of the file are used for the scenery. It follows that regional areas have the minimum size of a scenery tile (dependent on the location in the world, typically a few tens of kilometers).

In practice the condition is used to switch between the summer and winter texture schemes - whether it makes sense to allow the user to select winter textures for Hawaii is in the eye of the beholder.

In each definition file, what follows are the assignments of landclasses to materials, and condition and area holds for all of those in the rest of the file.

Material definitions

Let's take a look at a single block of material definitions:

  <material>
    <name>BarrenCover</name>
    <name>Dirt</name>
    <name>OpenMining</name>
    <name>Rock</name>
    <name>Dump</name>
    <texture-set>
      <texture>Terrain/rocks-lava.png</texture>
      <texture n="12">Terrain/rocks-desert.png</texture>
      <texture n="14">Terrain/rock_grain01.png</texture>
      <texture n="13">Terrain/void.png</texture>
    </texture-set>
    <parameters>
      <grain_strength>0.7</grain_strength>
      <transition_model>0.0</transition_model>
    </parameters>
    <xsize>1000</xsize>
    <ysize>1000</ysize>
    <solid>1</solid>
    <friction-factor>0.9</friction-factor>
    <rolling-friction>0.1</rolling-friction>
    <bumpiness>0.3</bumpiness>
  </material>

The first tags are name - they contain a list of landclasses the material refers to (remember that the landclass is stored with the terrain mesh, i.e. the mesh contains the information that a certain triangle is 'Rock').

The next block is the texture set assigned to the landclass - it contains the name of the files to be used for the visuals (to make use of Procedural Texturing techniques, usually multiple textures are assigned). The parameters block allows to configure procedural techniques by passing control parameters to the Shader generating the composite texture.

<xsize and ysize are important because they determine how large a patch the base texture file is supposed to cover (in the above example, 1000 m x 1000 m is covered by one texture sheet, if the sheet is 1024x1024 pixels, the base resolution is about 1 m).

The final set of parameters is passed to the FDM for ground interactions - we learn that 'Dirt' and 'Rock' are to be treated as solid surfaces and what their rolling friction and bumpiness is supposed to be. Using blocks like this, every landclass as stored in the terrain mesh is assigned characteristics that determine how it looks and behaves in FG when the scenery tile is loaded.

Note that using material definitions it is possible to merge different landclasses - in the above example triangles classified as 'Dirt' and 'Rock' will look and feel the same - but making two separate definitions instead, they could also be made to look differently. Again, a single landclass can not be made two different materials in the same region - later definitions will overwrite earlier ones.

Basic workflow

To make a regional texture definition for a region then, you need to

  • define a region by creating a file with a name, area and condition header
  • include this file in materials.xml
  • fill it with individual material definitions which are supposed to apply to the region

For the latter task, you may or may not have to

  • acquire suitable textures for the region
  • configure the procedural texturing parameters to generate good composite textures
  • assign random trees, buildings, materials, lights,...
  • assign surface properties