Version: 1.6.31.0
SDK: 1.6.0.0
Frequency: Consistently
Severity: Blocker
Marketplace package name: Not applicable
Context: ETM10m. When editing in DEV Mode.
Bug description: Hello everyone,
we would like to report a terrain/water blending issue that appears when using geodetically correct heightmaps in MSFS 2024.
Summary
When providing heightmaps where:
- DEM = ellipsoidal WGS84 (h)
- Sea = geoid undulation N (EGM2008) → so that H = h − N = 0 AMSL
- Land = h_DEM (ellipsoidal) → MSFS converts automatically to AMSL
…the simulator displays a deep vertical trench at the coastline.
This trench does not appear:
- in default MSFS terrain
- when using geodetically incorrect heightmaps (e.g., land raised by +N)
This suggests a blending issue between Heightmap tiles and WaterBody surfaces.
Repro steps:
Reproducibility
- DEM is ellipsoidal WGS84 (SNAP / Copernicus).
- Over the sea: set ellipsoidal height to
h = N (geoid).
- Over land: use the original DEM ellipsoidal height.
- MSFS correctly computes AMSL values:
- Despite correct geodetic behavior, a trench appears at the coastline.
Using an intentionally wrong heightmap (h = DEM + N) removes the trench but produces incorrect AMSL elevations.
Why We Think This is a Bug
- Geodetic math is correct.
- Geoid conversion is correct.
- AMSL values shown by MSFS debug tool are correct.
- Only the coastline blending fails when terrain is geodetically correct.
This indicates a possible issue in MSFS 2024’s terrain–water smoothing / skirt generation when a custom Heightmap overrides the base mesh.
Questions for Asobo / MS Team
- Should heightmaps be provided in ellipsoidal height (as per SDK)?
- Is coastline smoothing disabled when a heightmap tile replaces default terrain?
- Is this trench effect a known issue?
- What is the recommended workflow for precise DEM-based meshes?
Thank You
A fix or clarification would greatly help all developers working with high-precision terrain meshes.
ItalianCharter Team
Enhanced Terrain Mesh (ETM10)
Attachments:
Private attachments:
We will provide test packages, data samples, and additional measurements if needed.
via PM to @PrivateContent with the link to this topic and the link to download your content
Hello @ClevererElm8055
Let me make sure I understand.
So the elevation data you are working from provide the elevation as an offset to the geoid, and you write those values as is in the scenery heightmap data?
What data does your source provide for the sea? Nothing and you write N yourself, or the trench is already visible in your source data?
The trench you are talking about is present in the data you provide to the xml, this is not created by the engine.
For example, if you write a constant value for all heightmap points, you’ll have a “flat” surface with no trench.
The heighmaps are expecting ellipsoidal height, it’s up to you to account for the offset to geoid in the data you provide.
Regards,
Sylvain
Hello @FlyingRaccoon ,
thank you very much for the clear explanation and for taking the time to look into this.
Yes, your understanding is correct: the heightmaps we generate are written as ellipsoidal heights, and we fully agree that MSFS expects ellipsoidal values and does not apply any geoid correction internally.
Based on your clarification, it is now clear that the trench is already present in the data we provide to the XML, and not introduced by the engine. A flat, constant-height test confirms this behaviour.
At this point, the focus shifts upstream to the source DEM/DTM processing. In our case, the terrain data are produced via SNAP from Copernicus-based sources. While land elevations are well-defined, the sea areas are typically represented either as 0, nodata, or implicitly orthometric values, which leads to a discontinuity once the geoid offset is correctly applied to land elevations only.
This means the issue is not with MSFS itself, but with how marine elevations (or the lack thereof) are handled in the source DEM before writing the final ellipsoidal heightmap. We will therefore investigate more deeply how SNAP propagates or initializes sea-level values in the DEM, especially the origin and meaning of the 0 values over water.
Thank you again for the confirmation and for your time — it helped clarify the expected data model and narrow the problem to the correct stage of the pipeline.
Kind regards,
Giovanni
1 Like
Happy New Year 2026 to everyone,
Hi @FlyingRaccoon,
we’ve resolved the coastal trench while keeping a fully correct ellipsoidal DEM + EGM2008 workflow.
The issue is not datum conversion, but how near-sea DEM values are interpreted and interpolated at the coastline.
Applying a consistent sea-mask threshold removes the trench entirely.
PS:I have another related request for help on this ETM… I will open another specific post.
Regards
Gio
