Experimental DSM-based terrain renderer with streamed orthophotos

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