Mesh Overview: Quality
The term "Quality" means many things. For this discussion, I mean the realism of the terrain
as seen in the simulator. How well it represents the true topography of the earth (shape of the surface). There are three primary determinants of such realism. These define the potential
possible from the simulator, and apply to all users.
Elevation data for the US is freely available in many formats,
access to information for other countries is much less convenient and will not be discussed here, although the same principles still apply.
Both accuracy and quality of the source data must be considered.
Accuracy of the source data ultimately controls the realism of the result. Two factors determine this accuracy.
First, the recency and manner in which the data is collected. Much of the data for the US was collected over the last 50 years or more, much of out in the field;
some topographic features have changed since then, but this does not introduce many serious problems.
Up-to-date Shuttle Radar Tomography data is now being released, slowly. This will improve the data for the US, but only slightly,
as it is not of higher resolution than that currently available. The data for the rest of the world will be a significant improvement.
The horizontal distance between elevation measurements is the greatest contributor to accuracy. Common spacing of sampling points available for
some or all of the country are 90 meters, 30 meters, and 10 meters. 90 meter data has only one elevation data point for a 90 meter square; 30 meter data has 9 data points and
and 10 meter source data has 81 data points for the same area. This difference results in a much more accurate representation of uneven terrain.
Of course there will be no difference in realism for flat regions. Higher resolution data also means that smaller features will be included.
Quality of the source data is the final critical factor determining the quality of the final product. This aspect should not be readily apparent to the
user of the sim, but is important to the developer. There are two issues of concern here: the completeness of the data, and availability of data at the same
resolution for the entire region of interest.
Missing data can be as little as a single data point in the area; this will be obvious if it makes its way to the final mesh file.
The result is a large spike in the terrain, much like a telephone pole 32,000 feet high.
More problematic are the larger areas where data is missing along boundaries of USGS quadrants. Some of this is due to the fact that much of the data was
collected over 7.5 minute quadrants, at different times, by different people/organizations. There was little concern for matching these readings with adjacent quadrants.
This problem is further exaggerated by the new SDTS format used by the USGS, which introduces additional gaps at many boundaries. If this data is used as the source,
the developer must somehow fill these gaps. Otherwise the sim will represent them as (sometimes very obvious) artificial ridges and trenches.
Data for the entire country is not available at either 30 meter or 10 meter resolutions from traditional sources. "Gaps" involving entire 7.5 minute quadrants, or more,
must be filled with data at other resolutions. These transitions are often difficult to disguise in the sim.
The USGS NED data site attempts to address both issues by providing seamless 30 meter data, derived from a number of sources, and updated regularly. There are still
occasional missing data points, and anomalies where quadrants meet, but the result is much better for the production of high resolution mesh files.
Once suitable elevation data has been acquired, the developer must convert it to the format used by Flight Simulator. This can only be accomplished using the
Microsoft Terrain SDK (Software Developer's Kit) software. There are three factors under the control of the developer at this stage.
Cleaning up the data: the developer should make sure there is no missing data. Filling in missing single data points is easy, and can be automated.
Larger areas can require considerable resourcefulness. The result cannot be truly accurate (there was no data to work with), but the repair should be unnoticeable
Ensuring complete coverage of the area: In the conversion process, the SDK software trims the edges of the data to fit the MSFS grid. It is the developer's
responsibility to use large enough blocks of source data to provide for this, otherwise there will be gaps between high resolution areas, filled by the default terrain mesh.
This effect is usually visible as "cliffs" along quadrant boundaries (with regular spacing, often determined by the method used to merge multiple source files into a single BGL mesh file.)
Specification of the mapping of the source data to the internal MSFS geographic grid: It is helpful to think of this conversion as a
two-stage process. First, imagine that the terrain engine uses the original data to create a fictional 3-d representation of the terrain. The accuracy of
this surface is a function of the spacing of the original data. Then, imagine that the software goes out to that fictional area and takes a new set of elevation data points on
that surface, much like a surveyor; these new readings are the data which will be used to create the final mesh file.
The developer specifies the horizontal spacing of these new data points using the LOD parameter.
Common LOD values are 9 (76.4 meter spacing) and 10 (38.2 meter spacing). Once again, the closer these new sample points are (the higher the LOD),
the better they will capture the intermediate terrain surface. There is little value in increasing this accuracy if the source data and interim surface
are not very accurate, however. File sizes increase and performance suffers, with any additional improvement visible only using screen captures.
It is therefor best to try to match the final LOD spacing with the original data spacing.
For example, 90m -> LOD 9, 30m -> LOD 10, ... Exceptions can be made for various reasons, but this is a good guideline.
Finally, something the sim user can control.
Microsoft has balanced the default settings in the software so a user with hardware meeting it's minimum requirements will have a satisfactory
sim experience with a standard installation. They have also made it possible to enhance this experience in many ways.
Most of these enhancements impose additional processing requirements, and compromises usually have to be made;
adjustments to default settings allow us to allocate resources to those aspects of the sim that interest us most.
Using higher resolution terrain mesh is no exception. There is an undocumented parameter in the fs2002.cfg and fs9.cfg files under the [TERRAIN] section:
TERRAIN_MAX_VERTEX_LEVEL. The default setting is 19 and this is adequate for the default mesh supplied with the sim. There is not much data to display.
High resolution mesh (especially 30m source data or better) improves the realism of the sim, but not all of the data seems to be utilized with this default setting.
By increasing this setting to 20 or 21, we can see a noticeable increase in detail; both sharper peaks and smoother curves. There is a performance
cost for this additional detail, however.
When considering high resolution terrain to add to your simulator, check both the resolution of the source data
and the final resolution created by the conversion process; either alone is not enough, and absence of either in the product specification is grounds
for concern. Then consider adjusting your configuration setting so the software can use all the additional data available to it.