Caution: only tested with
MSFS 2002 and 2004
 


LOD Calculations

First, some theory. Think of the LOD grid system as a flat (Mercator-type) projection of the earth. Imagine a flat sheet of paper representing the earth's surface. The LOD grid system subdivides this surface into blocks, starting at LOD 0, with its origin at N 0º, E 0º. Each of these LOD 0 quadrants is 90º tall and 120º wide. The sizes of all other LOD level quadrants are based on these dimensions.

   LOD quadrant height = 90º / (2^LOD)

   LOD quadrant width = 120º / (2^LOD)

Using these formulas, the LOD 1 quadrants are 45º high and 60º wide. (For clarity, only one quadrant is shown subdivided here.) These are the Lat/Lon Degree Boundaries listed in the SDK LOD Table. Notice that each unit increase in LOD reduces the quadrant dimensions by half.

The Span, in Meters, is the size of the quadrant. There are 256 data points in each row/column, so the Sample Size = Span/256.

Now, an example. Let's calculate the bgl mesh coverage of 10-degree square subset of a GTOPO30 Tile. Our square has its northwest corner at N40 E20. We will use an LOD level of 7. Dimensions come from the LOD 7 row of the portion of the Terrain SDK LOD table provided below.

First the latitude. From the table, one LOD 7 quadrant is 0.703125º high, so:

 

N30º/0.703125 = 42.67 LOD 7 quadrants up from the equator.
44 is the first full quadrant above N30º
Its southern boundary is 43 * 0.703125 = N30.234º

 

N40º/0.703125 = 56.89 LOD 7 quadrants up from the equator.
56 is the last full quadrant below N40º
Its northern boundary is 56 * 0.703125 = N39.375.º


Now the longitude. From the table, one LOD 7 quadrant is 0.9375º wide, so:

 

E20º/0.9375 = 21.33 LOD 7 quadrants east of the Prime Meridian (E0.0º).
23 is the first full quadrant east of E20º
Its eastern boundary is 22 * 0.9375 = E20.625º

 

E30º/0.9375 = 32 LOD 7 quadrants east of the Prime Meridian (E0.0º).
since 32 is a whole number,
the western boundary of LOD 7 quadrant 32 coincides with the E30º meridian.


 

These coordinates can be entered directly into the .inf file for a more precise specification of the area to use, but the result will be the same as building the bgl using FSTerrain with the N40E020 northwest corner and 600 width and 600 height values.

If you are only constructing mesh for a single 10 x 10 degree area, this is the best you can do with an LOD of 7. (Higher LOD values give smaller quads and less loss, but introduce other problems.)

If you are going to build mesh for a larger area, more care in the production process can reduce the area left as default mesh.


 

How much better can you do?

In the example above,

 

The new mesh extends from quad 44 to 56 north (13 quads) and from 23 to 32 east (10 quads).
Each quad is 0.9375 * 0.703125 = 0.659º squared,
The total area is 13 * 10 quads * 0.659º squared per quad = 85.69º squared.
And the 10 x 10 degree block is 100º squared.
So the new mesh covers 85.69/100 = 85.69% of the total area.

For an entire 40 x 50 degree GTOPO30 Tile, N90 E100,

 

The mesh extends from quad 58 to 126 north (69 quads) and from 107 to 149 east (43 quads).
Each quad is 0.9375 * 0.703125 = 0.659º squared,
The total area is 43 * 69 quads * 0.659º squared per quad = 1955.79º squared.
And the 40 x 50 degree block is 2000º squared.
So the new mesh covers 1955.79/2000 = 97.78% of the total area.

This much improvement is easy to achieve, and developers should provide it. It is possible to go further, merging the data from adjacent GTOPO30 tiles, but the limited accuracy of the data probably does not justify the additional effort required.

Portion of the FS Terrain SDK LOD table
 
LODSample Size
Meters
Deg Boundaries
Lat
Deg Boundaries
Lon
Span
Meters
039136.29012010018863
119568.145605009431
29784.022.5302504716
...............
7305.80.7031250.937578272