Re: Experimental DSM-based terrain renderer with streamed orthophotos

Hi Gerard,

On Mon, Jun 1, 2026 at 11:59 AM Gerard Krol 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/


This does look very impressive, particularly the LIDAR resolution
picking up individual trees and shrubs.


> 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.
>

I don't think we yet have a policy on using AI on the project, but my
expectation is
that you as the author need to stand behind any contribution.  Which means
you need to have reviewed and understood all the code, irrespective of
whether
you wrote each line or used a tool.

We have enough of a challenge with old code that we're not familiar with,
without
making the problem worse :)


> - NL only, but should be easily extended to different regions if data is
> available in WMTS, WCS or comparable standards.
>

I think generic WMTS support would be very interesting indeed.  I can
imagine having
some low resolution worldwide definition, and then specific regional
definitions a bit like
we have regional material definitions so that it is contiguous, if not
seamless.


> - 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.
>

I think these problems are going to be hard to solve, and the oblique views
of buildings are really challenging without some additional photo reference.

- 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.
>

This is a fundamental issue with orthoscenery.


> - 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.
>

Be aware that 'next' uses a completely different HDR/PBR pipeline and
WS3.0 terrain engine.  In particular, there's no ALS, and how shaders work
is very different.

Please do reach out if you have any questions.

Taking a step back, one thought I had is that the WMTS element of this
might
work well as a way to deliver orthoscenery on WS3.0.  Indeed Curt mentioned
in passing to me using slippy-map tiles in a similar way.

At present orthoscenery is delivered as a separate set of textures that
are draped over the WS3.0 SRTM terrain mesh.  It works quite well, but
requires processing of the orthoscenery data in a scenery building stage
and
has a big storage impact on both server and client.

The approach you've demonstrated shows that it is possible to stream WMTS
as
orthoscenery at runtime.  That would remove the need to "build" the scenery
ahead
of time, any server-side storage impact for FlightGear.  It would probably
also allow
use of orthoscenery with more restrictive licensing, as FlightGearwould not
be
re-distributing it.

This approach would use the standard WS3.0 30" SRTM data rather than the
high
resolution LIDAR data.  However, that would mean that it could leverage the
existing Scenery
objects, osm2city and tree rendering without any gaps due to differences in
the DEM.
Given the issues you highlighted above regarding rendering buildings, that
might be a good thing.

-Stuart

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