1,360
edits
Howto:Regional texturing: Difference between revisions
Jump to navigation
Jump to search
→Background - terrain data structures
(Created page with "{{WIP}} 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...") |
|||
| Line 3: | Line 3: | ||
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. | 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 | == 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 <b>landclass</b> 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. | 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 <b>landclass</b> 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. | ||
| Line 10: | Line 12: | ||
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. | 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 <b>/Materials/regions/materials.xml</b> (for historical reasons, there are two alternative schemes under <b>/Materials/default/materials.xml</b> and <b>/Materials/dds/materials.xml</b> which are not supposed to be modified by regional definitions). They can be selected in-sim in the rendering dialog. | |||
<b>materials.xml</b> 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 <b>global-summer.xml</b> is considered (which is the world-wide default for summer textures), then the content of <b>hawaii.xml</b> overwrites the global definitions and finally the content of <b>oahu.xml</b> 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 | |||
<syntaxhighlight lang="xml"> | |||
<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> | |||
</syntaxhighlight> | |||
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: | |||
<syntaxhighlight lang="xml"> | |||
<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> | |||
</syntaxhighlight> | |||
The first tags are <b>name</b> - 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 <b>parameters</b> block allows to configure procedural techniques by passing control parameters to the Shader generating the composite texture. | |||
<b><xsize</b> and <b>ysize</b> 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. | |||