Caution: only tested with
MSFS 2002 and 2004

Realistic rendering of terrain mesh

Artificial mesh was created for this work so the transformations could be followed easily, with few complicating factors.

First, a 4685 row by 4685 column subset of 1/9 th arcsec data (~3.3m) was extracted from NED Dem data from the USGS. This data was then converted to a single elevation of 500m.

A series of five 2000m high columns was then created, with widths of 1 to 5 data points.

This data was converted to mesh using an LOD of 13 (~4.8m).

In addition, a 2000m flatten bgl was created nearby, using a very small width, which produces a flattened area whose size is determined by the underlying mesh.

Most testing was done in FS2004, with a TMVL setting of 21 and maximum terrain mesh complexity.

The tables below show how the data was transformed by Resample, and in the first table, how it was rendered in the simulator.

Table 1a (LOD13)

Elevation Column range Columns Resample Output FS peak Visible
2000 1700 - 1700 1 578 - 641 - No
2000 1800 - 1801 2 748 - 1972 746 Yes
2000 1900 - 1902 3 917 - 2000 - 521 521 Yes
2000 2000 - 2003 4 1086 - 2000 - 1852 1086 No
2000 2100 - 2104 5 1256 - 2000 - 2000 1994 No

Table 1b (LOD10)

Elevation Column range Columns Resample Output FS peak Visible
2000 1700 - 1700 1 - - No
2000 1800 - 1801 2 748 752 Yes
2000 1900 - 1902 3 521 521 Yes
2000 2000 - 2003 4 - - No
2000 2100 - 2104 5 - - No

* The Resample Output Column values are the elevations of the data points created for each of the columns in the bgl. The width (number of points) only approximates the width of the corresponding source column. Remaining values are the same as the base elevation, 500m

This source data was converted to mesh and evaluated in the simulator. Resample Output values were determined with TMFViewer. Clearly, the data undergoes considerable transformation at this stage. Peak elevations in the simulator were determined using my FSTelevation.exe utility.

Increasing the number of columns results in peak values closer to the actual source data. A minimum of 3 were required to include the source value in the bgl.

With the exception of the sample with 3 columns of data, Resample seems to introduce a bias resulting in higher elevations to the east of the peak than to the west.

When viewed in the simulator, the rendering of each column was quite different. (See the images below for more information)

1 value: This column was never rendered in the sim.

2 values: This column was always rendered, but the peak was far less than expected, given the values provided by the mesh.

3 values: This column was always rendered, but with a peak elevation just above the base mesh.

4 values: This column was always rendered, but never visible in the sim. The peak here was also far less than expected, given the values provided by the mesh.

5 values: This column was always rendered, but never visible in the sim. Only at this point does the rendered elevation approach that of the source data.

Table 2 (LOD13)

Elevation Column range Columns Resample Output
2000 2000 - 2004 5 1086 - 2000 - 2000 - 571
2000 2100 - 2104 5 1256 - 2000 - 2000
2000 2000 - 2002 3 1086 - 2000

At this point, I decided to look a bit closer at the impact of Resample on the source data. My first concern was whether the adjacent columns were affecting the outcome.

The first row produced results different from those using the same values in the table above, but I had placed the data in a different location. The second row, with the column now at the same location as in Table 1, suggests that the adjacent columns had no impact, but the position in the data array did!

Since the third (3 point wide) column was most disappointing, I moved its starting column from 1900 to 2000. Again, the new elevation values were very different, due only to the position in the data array. (In the sim, the elevation is now 1079m but is not visible)

Table 3 (LOD13)

Elevation Column Columns Resample Output
1000 2498 6 (total) 1051 - 1978 - 1595 - 668
1500 2499
2000 2500
2000 2501
1500 2502
1000 2503

Finally, I decided to see if the Resample process might use slope information to create an elevation point higher than the highest provided by the source data. It did not do so in this case.

The view from the simulator
This first image shows the aircraft positioned over the rightmost column, with a width of 5 data points. The FSTelevation window indicates that it is sitting on the ground. The actual peak is a single point at 1994m (determined later, with more careful positioning).

The TMFViewer window shows the elevated columns of data near the center of the block of artificial mesh.

These rows are barely visible on the ground, at the tips of their respectively numbered gray arrows. Although no visible textures are displayed revealing the heights of columns 4 and 5, the textures on the ground are different enough to distinguish the columns from the base 500m mesh level.

Columns 2 and 3 do have associated textures, and also have peaks defined by single elevation points.

To the left side of the screen, you can see the column created by the flatten bgl. This column is discussed below.

Below we see that the flatten bgl data is handled quite differently.

While the textures now show that the elevation is correct, they still come to a point at the top. The polygons defining the ground elevation are flat at the top, with the width of the top defined by the minimum resolution supported by FS2004.

The aircraft is sitting on the "ground", defined by the flatten bgl, some distance from the peak of the textures. The autogen tree is also "suspended" a short distance from the visible peak. This invisible feature is quite solid, and interferes with the range of motion of the Spot View Camera as well.

We have only begun to explore the factors the affect the rendering of mesh in Flight Simulator. No definitive conclusions can be drawn from this preliminary work. Rather, they suggest many more experiments we might conduct to learn more about how the various components work, alone and when interacting with one another.

These results suggest that the elevation data is expressed with its own set of polygons, relatively independent of the mechanism by which textures are positioned, or not!

Conclusion: There seems to be no practical visual benefit to creating mesh with an LOD value greater than 10. In addition, the results in the simulator were the same with TMVL setting of 20 and 21, so there seems to be no advantage to setting this value above 20.

For those who are interested, my FSTelevation utility is available for your own testing.

FST Elevation utility
(The "On Ground" feature does not work in Slew mode in FS2002.)

I've posted some results of preliminary testing which prompted this more detailed work:

early tests, different values