Re: Experimental DSM-based terrain renderer with streamed orthophotos

Hi Gerard,

I was expecting others to respond, but I suppose life is busy for everyone
here.  I just wanted to say that this is very cool in many ways.  It looks
like the elevation data accurately represents the tops of trees and
buildings, not the base ground level.  That leads to some interesting
results as you mention, but in many places it looks spectacular.

I think there are times when you just want the base ground, but other times
the first lidar reflection is pretty cool.  From time to time I wonder
about training a yolo model to pick out trees or other objects from the sat
photos (wouldn't really have to be that perfect.)  I know shadows are
cooked into the imagery, but for a wide range of conditions, that might not
be a big deal ... something most people would overlook most of the time (I
think.)

I noticed that MSFS took an approach where they started with sat imagery
drapped over (I think SRTM level) terrain data.  And I think they mixed
some other data bases ... water/rivers has been replaced so you can get
fancy reflections and wave animations, but then they've lost a lot of the
subtle details of sand bars in streams and shorelines.  Lighting
(buildings, streetlights, etc.) is a another whole thing at night ... MSFS
does a really nice job at that.  And then deciding if runways/taxiways will
be synthetically generated, or some how use/integrate the sat imagery to
get all the right cracks and paint lines and wear and tear ... except the
imagery is probably not quite high enough resolution.  I think it's super
cool to see the mow patterns in the grass around the runways on short final.

I know there is a lot of other great work going on with the FlightGear
WS-3, but I think this approach you are exploring is also quite promising
and has significant value.  Maybe some hybrid or cross polination of ideas
would lead to the ultimate nicest solution?  Creating a digital twin of the
Earth is more work load than one person should take on (unless you find
some pretty cool tricks, or know how to do it in 6 days.) :-)

Take care, your work looks very nice!!!

Curt.

On Mon, Jun 1, 2026 at 5:59 AM Gerard Krol <[email protected]> wrote:

> Hi all!
>
> After discovering the beautiful aerial photos from the Netherlands from
> PDOK, and the fact that 0.5m terrain data (DSM) is available, I've been
> working on a renderer for this over the past two weeks. Initially this
> was done in a separate project but now I've integrated it in FlightGear,
> as a proof of concept.
>
> This terrain renderer streams orthophotos and height data at runtime and
> renders them using a quadtree-based terrain system with
> displacement-mapped meshes.
>
> Screenshots are available at https://gerardkrol.nl/flightgear/
>
> Testing instructions:
> - clone https://gitlab.com/gckrol/flightgear and checkout the
> `dsm-stable` branch
> - build as usual
> - select a location in The Netherlands (recommended: EHAM,EHSB)
> - start with the `--terrain-engine=dsm` commandline flag (put this in
> Settings > Additional Settings in the launcher).
> - terrain will automatically be streamed in
> - happy flying!
>
> Performance
> Runs at 20-30 FPS on my 8 year old laptop at 1080p. I haven't measured
> it in FlightGear but the terrain should take only about 150MB VRAM, due
> to the wonders of BC1 texture compression.
>
> Licenses of used data
> - Aerial photo's: CC-BY 4.0 PDOK/Kadaster NL. Rate limits/etc. are not
> published. They do request a Referer header (and I assume a User-Agent
> one as well).
> https://www.pdok.nl/introductie/-/article/pdok-luchtfoto-rgb-open-
> - Heightmap data (AHN): Open data (no restrictions)
>
> https://www.pdok.nl/introductie/-/article/actueel-hoogtebestand-nederland-ahn
>
> Limitations
> - The code is currently experimental and needs cleanup, documentation
> and adaptation to FlightGear coding standards. Most of it is AI written
> and has had only limited review by me.
> - NL only, but should be easily extended to different regions if data is
> available in WMTS, WCS or comparable standards.
> - Sides of buildings sometimes look a bit weird on the ground or when at
> low altitude - I've experimented with some shader tricks in a separate
> project and this can probably be made less distracting.
> - Roofs of tall buildings may be misaligned due to the available data
> not being 'true ortho'. In a separate project I've experimented with
> manually/automatically aligning the data, and this improves appearance.
> This is outside the scope for now.
> - This does not have any controls for cache management, LOD settings
> etc. All could be easily added.
> - Always uses the default/basic fog, even when ALS is enabled.
> - Files are processed/compressed at runtime, even when loaded from the
> cache.
> - Photo's are taken during the day - so it looks slightly weird to see
> shadows under an overcast sky. I've experimented with a 'day for night'
> filter though and a moonlit night still looks fine. Also - shadows are
> baked in of course, so your nice sunrise/sunset will have mismatched
> shadows.
> - I'm already doing some processing on the heightmap tiles, but
> artefacts are still present in some locations, often in water. This
> should be fixable with some better processing logic.
> - The branch is based on FG 'stable', so would have to be transposed
> onto 'next'. As this is a quite isolated terrain system I'm not
> expecting major problems.
>
> Hacking
> If you want to start hacking on this (which I would highly encourage),
> here are some starting points:
> - The new code is in the terrain_dsm* files.
> - The WMTS url for the orthophotos is built in
> terrain_dsm_tile_source.cxx:169
> - The WCS url for the height data is built in
> terrain_dsm_height_source.cxx:248
> - Note: the renderer currently only supports the Dutch epsg:28992
> coordinates, so you'll probably have to adjust the code.
> - Downloaded tiles are cached in the FG download folder under DSM
> (default ~/.fgfs)
> - To load higher detail tiles in the distance, increase the 4.0 factor
> in terrain_dsm_orthophoto.cxx:shouldSubdivide
>
> Next steps
> - Try it and discuss it!
> - Figure out if this has the potential to be merged, and what's needed
> for it. Definitely needs settings and support for different regions (I
> believe ortho/height data is available for a lot of countries).
>
> I'll keep working on this for a limited time, but I would definitely
> welcome other contributors if people think the approach has potential.
>
> Let met know what you think!
>
> Regards,
>
> Gerard
>
>
>
> _______________________________________________
> Flightgear-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>


-- 
Curtis Olson

_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel