Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[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.

Red	Low byte of height
Green	High byte of height
Blue	Sign byte

This allows a height range of 32767 to -32767 metres. Should be enough 

Normal map

24 bits per pixel encoding of vertex normal

Type map

32 bits per pixel with the following mapping

Red	Texture 0 percentage
Green	Texture 1 percentage
Blue	Texture 2 percentage
Alpha	Texture 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]

Water is encoded in the type data.

Excellent! Thank you!

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.

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.

[asheshouse]

Given that we can obtain sea bed height data, would it be possible or practical to have tidal effects. In particular i am thinking of the changing visual scene in shallow tidal waters.

[SAS~Bombsaway]

Since I love making shallows textures, you have my attention with this.

[Pursuivant]

Since I love making shallows textures, you have my attention with this.

If water depth is easy to calculate, it might be possible to automatically generate shallow water textures by "shading" underwater objects and terrain based on light diffraction with depth and water turbidity.

That would have other benefits, such as allowing objects submerged in shallow water to remain partially visible (at least from the air). That would allow for realistic sub-hunting operations and would allow wrecks of sunken ships to remain visible on campaign maps.

Albedo mapping could also be used to automatically map things like snowy, muddy or burned out areas allowing for quick creation of seasonal maps or maps where defoliants or fires have altered the landscape.

[Stainless]

The main problem is that SRTM data is from orbital scanning. So it "sees" water as terrain and reports the height of it.

I need to find a way of getting data for underwater features as well.

IF anyone has any ideas for that, please yell loudly..

[Pursuivant]

The main problem is that SRTM data is from orbital scanning. So it "sees" water as terrain and reports the height of it.

I need to find a way of getting data for underwater features as well.

IF anyone has any ideas for that, please yell loudly..

STRM data can be used to estimate bathymetric data, albeit not with great precision for deep oceans. Apparently, estimation of depth ranges from +/-10m for shallow waters to +/-100 m for deep ocean features. That's one of the reasons why seafloor maps are more accurate for coastal areas, but practically useless for deep ocean areas (e.g., during the search for MH370).

It's been a while since I've worked with STRM data, but the data sets on this site might be what you're looking for since they integrate standard STRM data plus bathymetric survey data:

http://topex.ucsd.edu/WWW_html/srtm30_plus.html

[Stainless]

Well some progress this week.

The tool generates a palette table for each 1 degree section of SRTM data. This defines the textures used to display the terrain and the water state of the patch.

So far I have 0 == sea, 1 == standard (sand,grass,rock,snow) 128 == deep ocean 129 = standard + sea

So we have support for 127 different palettes. Should be enough.

I have basic streaming in, but still needs work.

This video shows a lot of bugs I have to fix, and a lot of features missing, but it does have a day night cycle and I can recognise the terrain as being were I live.

For me it is quite depressing, So much work to do......

https://youtu.be/OmlJQqDSnYo

[Pursuivant]

Was my link to bathymetric STRM data helpful?