FSXA Terrain mesh problem

Hi Alex:

I hope to do a few additional tests this week to see what might be done to attenuate the exaggeration of the peaks at the edge of the terrain mesh where the coastline polygon cuts down to sea level. ;)

I anticipate such a process may help avoid anomalies such as under discussion in this thread, when over-sampling is utilized in FSX SDK Resample with lower resolution source data to generate a (artificially) higher quad matrix grid resolution which would allow rendering a highly-detailed coastline in FSX at run-time. :)

Last edited:
Hi Alex:

Sorry for getting caught up in some digressions in other threads, and for having over-committed myself during the last week or so. :eek:

It seems one will need to over-sample the ASTER GDEM2 source data in FSX SDK Resample to generate a terrain mesh which enables sufficient FS terrain grid vertices to allow a detailed coastline for Lampedusa (and potentially also for Samos).

FYI: It will be difficult, if not impractical, to perform multiple trial-and-error tests by pre-manipulating ASTER GDEM2 elevation source data to offset "vertical exaggeration" imparted to the terrain output shape as 'coastline peaks' during over-sampling by FSX SDK Resample.

Thus, to achieve a more predictable result with a more efficient workflow, it may be more appropriate to implement a modification to the local shape of those 'coastline peaks' in their final form as imparted to the output terrain mesh BGL during over-sampling by FSX SDK Resample.

Use of 1 or more sloped flatten(s) in (a) separate CVX vector BGL(s) may "re-mesh" the final 'shape' of the terrain in the problem areas at run time in FS. :idea:

It would be helpful to first identify the most likely "correct" elevation for the edges of the coastline which apparently are slightly raised in real life based on photographs of the project area (but which are not actually "peaks" such as imparted by Resample due to the desired over-sampling used to enable more terrain vertices at closer intervals within the quad matrix grid); this may be possible to establish via comparison of elevation data from topographic maps or various DEMs of Lampedusa.

Then, using that info, one can construct a corrective terrain "surface" to properly "shape" the terrain for that area via the methods for making sloped / tilted flatten CVX vector BGLs ...as discussed in a number of threads here at FS Developer.

PS: In addition to insights you may derive from searches via Google using query strings of ex: "FSDeveloper" and "sloped flatten", you may be interested in following the ideas discussed and linked in this recent thread:


Feel free to ask any additional questions about how to further modify the shape of your detailed coastlines made possible by over-sampling elevation source data when making FS terrain mesh BGLs. :)

Last edited:
Hi Gary,

My apologies for replying after quite some time, i got caught up in some family business etc. :eek:

Anyway, back to the matter in hand . Unfortunately sloped flattens as a way of correcting the terrain anomaly is a no-go, i found it too tedious and time-consuming to say the least as a solution for the problem. Do you think maybe by acquiring more accurate DEM data (i.e 5M resolution) the problem would be resolved?
Last edited:


Staff member
Resource contributor
I think the problem is your water mask does not match the elevations. Sometimes Google, or other map sources are slightly off in registration. Sometimes the mesh is off. It just happens. Aster mesh in particular has not been adequately processed.

Indeed that is true, i am thinking of acquiring DEM data from a terrain solutions company like Intermap etc, only when i am assured that the problem would be resolved.
Hi Alex:

Sorry for the delay in replying here... I've been rather busy as well. ;)


Indeed, using a more accurate DEM may help make it much easier to control the development process of you are trying to achieve.

However, one must still ensure proper size / shape, as well as horizontal ("X-Y" or Lon-Lat) and vertical ("Z" or elevation) alignment of all one's terrain scenery component layers including vector, raster, and mesh content. :alert:

Making copies of a master terrain scenery object (such as the island's custom vector shoreline polygon) used as a "template" for creating, positioning, or comparing with other scenery layer objects and masks, may help maintain alignment for a project.

NOTE: If you find that the cost of commercial DEM elevation data at higher resolutions is too prohibitive for your island projects, I'd suggest that making an over-sampled mesh from ASTER GDEM2 data would provide the mesh data and terrain quad matrix grid vertex resolution required for a detailed shoreline to be displayed at the level of detail you apparently want.

As you can see from the table I posted in this thread:


...the FSX SDK Resample LOD output resolution of the BGL (when lower-resolution DEM source data is purposely over-sampled) will depend on how close together you need / want your terrain vector vertices.

If, for example, you wanted to use the minimum default inter-point distance interval in SBuilderX at 20 Meters (62.99194 Feet) between FS terrain vertices defining a poly-line or polygon, you would require a terrain mesh BGL with at least a LOD-11 output resolution (to allow 19.2 Meters between Area Points in the FS quad matrix grid "if" the terrain mesh resolution slider of FSX is also set at 20 Meters or less with the FSX mesh complexity slider set at 100 %).

And if instead you wanted to use an even smaller inter-point distance interval in SBuilderX of ex: 10 Meters (31.34731 Feet) between FS terrain vertices defining a poly-line / polygon, you would require a terrain mesh BGL with at least a LOD-12 output resolution (to allow 9.6 Meters between Area Points in the FS quad matrix grid "if" the terrain mesh resolution slider of FSX is also set at 10 Meters or less with the FSX mesh complexity slider set at 100 %).

IIUC, one would also need to pre-configure SBuilderX to allow use of a smaller inter-point sample distance interval of ex: 10 Meters (31.34731 Feet) between FS terrain vertices when defining a poly-line / polygon ...by editing this SBuilder.ini file parameter to read:

SampleDistance= 10

However, the terrain mesh elevations resulting from over-sampled ASTER GDEM2 data may have anomalies (such as was the original basis for this thread); IMHO, correcting / minimizing those anomalies might best be done via CVX vector 'sloped flatten' polygons.

BTW: If you wish to preserve the details of the rocks extending out into the water at the base of the cliffs along the coast of your island(s), you must re-work the default and/or other underlying water hydro polys to allow the terrain mesh to "pop up through the water" and enable display of the raised terrain mesh elevations (rather than being displayed as textures draped over the flat water surface); AFAIK, this is all to be achieved via vector / raster exclusion / replacement / masking processes which require precision shaping and alignment using ex: SBuilderX.

And, as Rhumbaflappy points out, the ASTER GDEM2 still has not been revised as extensively as other DEM sources to minimize various anomalies, and some world areas may require more work to clean it up than in other areas.

I would not try to use sloped flattens along the shoreline at the level of the water, as that should IMHO, be fixed via terrain scenery component layers of vector and raster excludes / polygons / textures / masks.

Instead, you may wish to make smaller local sloped flattens to attenuate the extent and shape of the anomalous vertical elevation "peaks" discussed above.

And rather than including the shorelines themselves within the sloped flattens, you may wish to try simply having the edges of the sloped flattens "meet" the vertices of the underlying terrain mesh at the "in-land" edges of the shorelines ...before they drop down to sea level. :idea:

PS: I would again encourage you to consider testing the ideas regarding pre-alignment of one's terrain vector vertices (for ex: sloped / tilted flattens) onto the known vertex positions of the FS quad matrix grid, to minimize possible additional run time terrain engine rendering anomalies which may complicate the excessive "vertical exaggeration" incurred when oversampling DEM data in FSX SDK Resample ...as discussed in this thread:


FYI: If the geographic coordinates of one's custom vector vertices 'fall in-between' the terrain vertices of the FS quad matrix grid, at run time during a flight, the FS terrain rendering engine may create pits, spikes, or otherwise exaggerated negative or positive elevations either close to (or wildly out of keeping with)- the elevation "requested" at our own specified terrain vector vertex positions ...resulting in terrain anomalies via a mechanism independent of those induced by Resample due to over sampling of terrain mesh source data. :pushpin:

Thus, we may sometimes need to use a FS SDK Resample higher LOD resolution output for a terrain mesh BGL (even if source data resolution is lower than the intended output LOD) to create a greater density of terrain vertex positions which are closer together, in order for our custom terrain vector points to be able to align with the FS quad matrix grid Area Point positions, thereby allowing us to render and display the desired shape for our terrain at run time during a flight ...with less risk for anomalies. :teacher:


Hope this helps ! :)

Last edited: