the SAS Hangar > Stainless' new Flight Simulator

Terrain

(1/6) > >>

Stainless:
After a LOT of experimentation, I have got fed up with messing about and just made a decision.

The system will use displacement mapping under a quad tree mesh.

So I need to generate a lot of texture maps.

Height map

The height map is 24 bits per pixel with each channel having the following mapping.

RedLow byte of heightGreenHigh byte of heightBlueSign byte
This allows a height range of 32767 to -32767 metres. Should be enough  :D

Normal map

24 bits per pixel encoding of vertex normal

Type map

32 bits per pixel with the following mapping

RedTexture 0 percentageGreenTexture 1 percentageBlueTexture 2 percentageAlphaTexture 3 percentage
Each terrain region is assigned 4 surface textures based on altitude and slope. Think sand - grass - rock - snow. These are mixed based on the type textures pixel.

All this is auto generated from SRTM data.

At the end of this you have a "bare earth" terrain patch.

This is imported into an editor so each area can be detailed by hand, but will work as is without detailing.

If a detail map is available, the type map is only used for physics. Detail maps are stored by time range. So we can have different terrain details for each time period.

Here are some examples, I still have to split them down to terrain patches.








Pursuivant:
Question: Does water level work independently of terrain height?

That is, does your terrain mapping allow for water features at different elevations on the map or subterranean terrain features?

Both are problems with current IL2 maps.

Having water level values independent from terrain elevation values could also allow easy generation of areas subjected to flooding, drought, or artifical controls on water level (e.g., canal locks or reservoirs), as well as creating areas of shallow water which might interfere with ship movement or water landings by aircraft. It might even be possible to program rise or fall of water levels to simulate things like tides, currents, or drainage.

For WW2 maps, being able to easily map water levels independent of terrain would be incredibly useful for generating realistic maps of areas like Scotland, Norway, or the Normandy Coast (where tidal variations can be quite high) or China or Holland (where flooding was used to deny terrain to the enemy).

Stainless:
Water is encoded in the type data.

At the moment I am struggling to find a way to automatically generate this data, but if all four bytes of the terrain type pixel are 0, then it's water.

This can be at any elevation.

So rivers can flow down hill, terrain can be dry and below MSL, etc.

Pursuivant:

--- Quote from: Stainless on May 02, 2018, 02:33:55 AM ---Water is encoded in the type data.
--- End quote ---

Excellent! Thank you!


--- Quote from: Stainless on May 02, 2018, 02:33:55 AM ---At the moment I am struggling to find a way to automatically generate this data, but if all four bytes of the terrain type pixel are 0, then it's water.
--- End quote ---

Port data over from an albedo map?

e.g.,

https://modis.gsfc.nasa.gov/data/

https://modis-images.gsfc.nasa.gov/ALBEDO/index.html

There is a specific dataset of MODIS map data which is used to mask water areas.

https://modis.gsfc.nasa.gov/data/dataprod/mod44w.php

Alternately, use more a more general albedo map data set and set albedo of water (~0.06) = 0,0,0,0 on your STRM data map.

Not only would the latter option automatically give you water features, it would also give you rough ecosystem data allowing autogeneration of things like forests, ice fields, grasslands, or deserts. If someone wanted to get really fancy, it could also be used as a base for modeling things like dust storms, forest fires, or haze.

Stainless:
I have now solved one major problem, when I generate tiles I also have to generate vertex normals.

This turned out to be very complex, most techniques commonly used end up generating nasty linear features in the normal map. At first I thought it was a bug in my code, but then I tested using xnormal and found they have exactly the same problem. So they just use a blur filter to smooth things out.

I now generate a surface normal for every triangle in the height map, accumulate that on a per pixel basis.  Normalise it. Then blur the generated normal map.

Here is an example patch

Height



Normal map



Each one represents 1 minute of latitude / longitude. So from each HGT file you end up with 60*60 or 3,600 bitmaps.

This gives a resolution of about 2m per pixel at the equator, and about 1.7m per pixel at 45N

When I drop a couple of the generated files into my test code, you get a display like this.



This is two generated patches displayed side by side.

Navigation

[0] Message Index

[#] Next page

Go to full version