Discussion Thread about the wiki article "Create mesh using Global Mapper"

[ScKevin]

Hi guys,

as I finally finished my first wiki article about creating mesh using Global Mapper, I opened this thread for discussions, suggestions, needed help,... so that we have everything about this article in one thread.

Go to the article in the wiki

So if there are any problems, suggestions,.. feel free to post them here!

 

[mmann]

It's interesting to see an alternate workflow (compared to mine) for Global Mapper. The program has many features and allows great flexibility in preparing data.

The Resample.exe data example given is adequate for a quick test, but for a larger project and better control of the output I highly recommend the use of an LOD range (instead of Auto) and making use of both CompressionQuality and FractionBits.

 

[ScKevin]

Interesting point for LOD since I was always told to use Auto as resample.exe recognises the optimal setting for it and as Auto does not leave out informations. However I am not sure if different LODs are needed in FSX/P3D since more LOD layers mean more VAS or are the not needed LOD layers cleaned out of the RAM when they are obsolete?

 

[mmann]

Here is a comparison between LOD Auto and LOD 4-11 (all other parameters the same):

Auto actually included more LOD's (with 0 to 3 being included) than the LOD 4-11. These extra LOD's aren't needed as the default mesh covers these. Sometimes you want to set the LOD artificially high so that your mesh has priority over some other 3rd party mesh. Finally, I have sometimes had LOD Auto miss giving me the highest mesh LOD number represented within an area.

Setting LOD values for both the lower and upper limit guarantees that your mesh includes exactly what you want.

 

[ScKevin]

I see in the pictures posted above that there is at least for my eyes no differences in the elevation model. And your point about setting LOD like what I/you want is more than right. But the problem what I see is that if people are playing too much with LOD like setting it to 20 (with the idea of higher is better since more detail) most of them forgot that the source data also needs to support this and until now there is to my knowledge no data available in that high LOD for an reasonable price. And at this point we will not speak on the performance impact in FS2004/FSX/P3D of such high LOD numbers.

To see if I got that right, you suggest to compile the mesh once with LOD 4 and once with LOD 11 or did I get that wrong?

 

[mmann]

To see if I got that right, you suggest to compile the mesh once with LOD 4 and once with LOD 11 or did I get that wrong?

No it's much simpler than that.
Replace the line LOD = Auto with LOD = 4,11

With just that one line change you take control of the LOD levels. The mesh is still compiled once, exactly as before.
As far as the differences in the pictures posted, note the border area of LOD Auto which is showing the superfluous LOD levels 0-3.

 

[GaryGB]

Hi Kevin:

First, a "heads-up" regarding Global Mapper behavior when opening data files, within the context of a Step-By-Step guide for "Exporting" source data for use with FS SDK Resample to make a terrian mesh BGL:

http://www.fsdeveloper.com/forum/threads/about-geotiff-resmaple.430118/#post-671613



CAVEAT: I believe that it is a good idea for one to always:

1.) first make backups of all source data files

2.) then work with COPIES of ones source data files.

Thus, IMHO, one might consider the Global Mapper "Batch Convert" procedure only with COPIES of ones source data files.



Also, although one 'can' use 32-bit source data with FS SDK Resample to make terrain mesh, IMHO, one should instead "Export" elevation data as 16-bit from Global Mapper for use in FS SDK Resample to make terrain mesh with the FractionBits parameter in ones INF file.


The reason is that in nearly all scenarios I've tested with high resolution terrain mesh, there is a substantial penalty to FS run time performance when processing miniscule fractions of a Meter for ground elevation from 32-bit values in the terrain mesh BGL which affects the time required to resolve the triangulated ground surface within Area Point "mini-quads"; this subsequently further delays texture draping onto the ground surface.

AFAIK, it is unlikely the end user will see subtle differences in the appearance of terrain surfaces when rendered from 32-bit versus 16-bit data compiled with FractionBits due to the way the FS rendering engine renders even very high resolution ground textures on top of terrain surfaces.


BTW: An interesting in-depth discussion of precision in terrain mesh creation is here:

http://www.fsdeveloper.com/forum/threads/geotiff-mesh.4339/page-2


Additionally, readers are cautioned regarding use of ASTER GDEM as source data (as used in your 'worked examples') since that data set still has significant accuracy issues which has yet to be "cleaned up".

* "Most" ASTER GDEM data sets are released as 'minimally-cleaned' 45 Meter resolution

* "Some" ASTER GDEM data sets are released as 'partially-cleaned' 30 Meter resolution


FYI: FS Developers with a goal of precision terrain rendering have been advised to consider other options as elevation data sets evolve:

http://www.fsdeveloper.com/forum/threads/global-1-arc-second-srtm.432642/

http://www.fsdeveloper.com/forum/threads/gis-data-sources.213907/


PS:

3 Arc Second is 90 (aka in FS="76.8") Meters between elevation data points (SRTM horizontal resolution)

1 Arc Second is 30 (aka in FS="38.4") Meters between elevation data points (3x that of SRTM horizontal resolution)

1/3 Arc Second is 10 (aka in FS="9.6") Meters between elevation data points

1/9 Arc Second is ~3.3 (aka in FS="4.8") Meters between elevation data points


Thanks for your initiative in contributing a WIKI for terrain mesh creation here at FS Developer !

GaryGB

 

[mmann]

Also, although one 'can' use 32-bit source data with FS SDK Resample to make terrain mesh, IMHO, one should instead "Export" elevation data as 16-bit from Global Mapper for use in FS SDK Resample to make terrain mesh with the FractionBits parameter in ones INF file.

Here is what Holger Sandmann (who did most of the mesh for the payware Orbx FTX Regions) has to say:

Hi guys,
for most 10-m terrain mesh files I use the following parameter values:
CompressionQuality = 97
LOD = 4,12
FractionBits = 2
The FractionBits option is very valuable to prevent visible terracing, especially on gentler slopes, like George's screnshots prove. However, in order for this to work properly one needs to make sure that the source files have sub-meter vertical accuracy (meaning not stored in integer format with 1m or 1ft stepping) and also that any re-projected or subset input files (via Global Mapper or other tools) are stored in floating point (32-bit) format.

 

[NoNewMessages]

Only quick and fleeting comments, as I have work to do.

I've yet to experience any performance issues due to the addition of mesh, sometimes down to 1m resolution. Not saying it can't or doesn't happen, only that I've created a gamut of files at 32 bit and not seen any apparent issues.

Batch/Conversion can be a problem when making GeoTiffs for Resample and I do not know why. The compiler complains and doesn't yield a file. Doing the same process that would be done under Batch/Conversion as a Global Mapper script, where I do a directory wide alteration of files yields files that Resample will process.

 

[GaryGB]

Here is what Holger Sandmann (who did most of the mesh for the payware Orbx FTX Regions) has to say:

Hi guys,
for most 10-m terrain mesh files I use the following parameter values:
CompressionQuality = 97
LOD = 4,12
FractionBits = 2
The FractionBits option is very valuable to prevent visible terracing, especially on gentler slopes, like George's screnshots prove. However, in order for this to work properly one needs to make sure that the source files have sub-meter vertical accuracy (meaning not stored in integer format with 1m or 1ft stepping) and also that any re-projected or subset input files (via Global Mapper or other tools) are stored in floating point (32-bit) format.

Hi Mike:

Indeed, Holger's insights are quite relevant to the IIUC, types of terrain and elevation range scenarios he describes in that quote.


And certainly use of 32-bit source data allows considerably more control without as many "gotchas" (ex: terrain getting 'clipped off' at certain elevations due to improper use of higher FractionBits settings, which, IIRC, Lance has previously alluded to elsewhere).


Here's what the FSX Terrain SDK - 'The Resample Tool' doc says:

https://msdn.microsoft.com/en-us/library/cc707102.aspx#TheResampleTool

FractionBits - integer values

"By default height values are stored as 16 bit signed integers (in meters). If FractionBits is set then the specified number of bits determine the fractional part. For example, if FractionBits is set to 1, then 15 bits hold the interger part and one bit holds the fraction part and an accuracy to 0.5 meters is possible. If it is set to 2 then accuracy to 0.25 meters is possible, and so on. The drawback of setting FractionBits is that it reduces the overall range of possible height values, though only in very mountainous regions, or with a high number of fraction bits set, is this likely to be a factor. For example if FractionBits is set to 3, then height values are stored to 0.125 meter, with a range in height set by the remaining 13 bits of 8192 meters (-4096 to +4096 meters). Height values are always interpreted as signed integers, even if a BaseValue is set.

See the examples in the section Using Scaled Elevation Values below."

https://msdn.microsoft.com/en-us/library/cc707102.aspx#UsingScaledElevationValues


Hope this helps !

GaryGB

 

[mmann]

Since we're discussing workflow, here is mine:

In Global Mapper is as follows:
1. Open the dem files required in Global Mapper (the most I usually do at once is 32 files)
Note: always make sure that when all the files are loaded they can be encompassed by a rectangle or square with no blank area.
2. Go to menu Tools/Configure...
3. On Projection Tab of Configuration change Datum from NAD83 to WGS84
4. Go to menu File/Export/Export Elevation Grid Format...
5. For Select Export Format select GeoTiff
6. In GeoTIFF Options tab for File Type select Elevation (32 bit floating point samples)
7. Select "Interpolate to Fill Small Gaps in Data

For Resample Tool
1. Select MultiSource and set the number required; I did all of Vancouver Island & adjacent BC Mainland in two bgl's
2. CompressionQuality = 97
3. LOD = 4,11
4. FractionBits = 2

The upper Limit of LOD will be determined by the resolution of the dem files. In my case (Canada West Coast) the resolution was 19m so that dictated an upper LOD limit of 11. If I wanted to match FTX PNW mesh I would have used an upper limit of 12 to match what Holger did for south Vancouver Island (Holger had to accommodate the Washington State area 10m mesh included with his south Vancouver Island area).

 

[mmann]

Indeed, Holger's insights are quite relevant to the IIUC, types of terrain and elevation range scenarios he describes in that quote.

Not just Holger, but Dean Mountford (FS Dreamscapes) and Justin Tyme (then FSGenesis) both compiled under 32 bit starting in 2007. The only downside expressed at that time was the extra hard drive space required, which by today's reality isn't worth mentioning.

Of course if I was doing mesh for just Manitoba or Saskatchewan I wouldn't bother using 32 bit (actually I wouldn't bother doing mesh for that area at all, flat is flat).

 

[ScKevin]

As I had now finally one afternoon free, I overhauled the tutorial a bit and changed/added several things. If you can still find some mistakes, feel free to point them out! I am also grateful to everyone here who helped to fix the tutorial!

 

[GaryGB]

Not just Holger, but Dean Mountford (FS Dreamscapes) and Justin Tyme (then FSGenesis) both compiled under 32 bit starting in 2007. The only downside expressed at that time was the extra hard drive space required, which by today's reality isn't worth mentioning.

Of course if I was doing mesh for just Manitoba or Saskatchewan I wouldn't bother using 32 bit (actually I wouldn't bother doing mesh for that area at all, flat is flat).

Yes, Mike, over the years, I have indeed reviewed rather extensively such info posted on use of 32-bit versus 16-bit source data for terrain mesh, as well as use of FractionBits; using 32-bits IMHO can be helpful (and even required) for "certain" elevation source data processing scenarios when creating FS terrain mesh.

Even though in most other aspects of FS development I am otherwise inclined to use (and 'advocate') greater precision in source data processing, for a number of reasons, IMHO, it is best to use 16-bit source data for the vast majority of cases when making FS terrain mesh.


FYI: The default mode in Global Mapper utilizes automatic interpolation of data in all displayed layers of gridded data (ex: DEMs / DTMs), so that when 16-bit and 32-bit data is displayed, export of the data within the workspace into ex: a 16-bit raster elevation GeoTiff may already have had "smoothing" of 'terracing' seen in certain elevation data sources such that FractionBits may not even be needed during processing by FS SDK Resample ...in 'some', if not 'most' scenarios.

And, of course, one can always utilize 32-bit elevation source data and "down-sample" it to 16-bit when exporting from Global Mapper.


GaryGB

 

[GaryGB]

As I had now finally one afternoon free, I overhauled the tutorial a bit and changed/added several things. If you can still find some mistakes, feel free to point them out! I am also grateful to everyone here who helped to fix the tutorial!

Thanks for the update, Kevin !

GaryGB

 

[Muzikman]

Greetings! I'm new to the FS design scene! but i think im falling in love with it! in the "Making our elevation data ready for flight simulator" section of the Terrain wiki article, can someone please explain exactly what the "FS2004 SDK rules" are? I thought maybe it was in one of the documents that came with the terrain sdk, but all the docs are barely readable.. unless im looking in the wrong place..

Thanks in advance!
MM

 

[ScKevin]

...can someone please explain exactly what the "FS2004 SDK rules" are?

Hi MM! The term "FS2004 SDK rules" is quite a bit misleading. Therefore I updated that phrase for better understanding. The "FS2004 SDK rules" was a simple way to say that you need to read, understand and apply the definitions, etc.. which the FS2004 Terrain SDK gives you in the Creating Terrain.doc-file. I also directly added with the updated phrase a link to the FS2004 Terrain SDK, so that people can instantly get what they need. Hope this clears this at least a bit, if not ask

 

[Muzikman]

Hi MM! The term "FS2004 SDK rules" is quite a bit misleading. Therefore I updated that phrase for better understanding. The "FS2004 SDK rules" was a simple way to say that you need to read, understand and apply the definitions, etc.. which the FS2004 Terrain SDK gives you in the Creating Terrain.doc-file. I also directly added with the updated phrase a link to the FS2004 Terrain SDK, so that people can instantly get what they need. Hope this clears this at least a bit, if not ask

Ahhhhh ok, I see! Well my next question is this: So is my .inf file for fs9 gonna look similar to your example? The reason I ask this is I'm trying to make sense of the Creating Terrain doc in the SDK. I think Notepad on my computer is opening the docs incorrectly or something. It's really hard (for me lol) to distinguish between the actual information or some hyperlink numbers, characters and letters and stuff lol.. i just dont want to delete the wrong stuff! so i can move forward haha..

 

[ScKevin]

Open the file with an application similiar to Word or so, then you get no problems
About the .inf itself: yes it looks similiar, but usually some lines change due to a different interpretation of the resample.exe if I am not mistaken.

 

[Muzikman]

Open the file with an application similiar to Word or so, then you get no problems
About the .inf itself: yes it looks similiar, but usually some lines change due to a different interpretation of the resample.exe if I am not mistaken.

Will do! thank you so much!