Re: Experimental DSM-based terrain renderer with streamed orthophotos

I'm going to refer to something that was mentioned here earlier about potentially streaming orthophotos from other sources instead of storing them in TerraSync: I think this is a good idea, and we can definitely give it a shot in WS2. While I wish it could work with WS3, practically speaking, it wouldn't.

WS2 uses a very different tiling system than WS3, where at any given time you are only rendering a few tiles at a time, say 20. Making the orthophoto requests concurrently with TerraSync should work well, and I don't really foresee many issues with this: that is partially how the original Julia script works, just a bit slower.

WS3, on the other hand, has LOD in its scenery, with 1x1 degree tiles being broken up into 16x16 grids. While you'll only ever be rendering 4 tiles at the maximum (if you're at a corner, for example), each one of those tiles will require 1024 requests for the highest levels of detail. Even rendering one tile at a time, this is not something that can be reasonably kept up with. Querying the ortho server fast enough to keep up with TerraSync will inevitably result in 504s for most requests, and now you have snaggletoothed terrain rendering. If you pace your requests to not overload the server, you are now waiting several minutes to download a single tile of scenery. That's alright if you're downloading ahead of time, but unusable if you're trying to download on the fly.

The only real solution to this would be to process there orthos ahead of time and ship them with TerraSync, more or less similar to osm2city. However, even at 2K resolution, storing all of those tiles in our mirrors will almost certainly exceed the current size of everything else we currently have there, perhaps even including osm2city. 4K would certainly do that, without a doubt. I'm not sure what the pricing is for keeping those servers up, but that surely can't be cheap.


________________________________
From: Stuart Buchanan <[email protected]>
Sent: Tuesday, June 2, 2026 08:09
To: FlightGear developers discussions <[email protected]>
Subject: Re: [Flightgear-devel] Experimental DSM-based terrain renderer with streamed orthophotos

Hi Pat

On Tue, Jun 2, 2026 at 2:57 PM Patrick Callahanwrote:
Amazing.

Would that .5m resolution be the cause of the "jello mold" look of some of the buildings?  Is it possible to detect that effect and properly blend the surrounding scenery with a straightened building wall with an appropriate texture?

Osm has building locations and footprints apparently taken from our city tax authority's data.  I'm assuming that if we had .5m-resolution lidar data for our area, it could be matched and used to correct the lidar data, yielding a reasonable approximation of the roof shape,  height and and building footprint.  Is it possible to use common textures for the front and sides of residential buildings based on roof height and widths taken from the building outline?  That's a lot of processing, but the result could be quite realistic viewed from 1000' agl.  Buildings near airports might need better modeling, as the minimums there would be lower.

Well, that's kind of what osm2city does.  Except it does it as a scenery building step, and uses the OSM data for height.  It should be the case that the OSM data can be updated with the LIDAR height information, if it hasn't already been done.

Apparently, there is now an open global database of building outlines in 3d format:

https://essd.copernicus.org/articles/17/6647/2025/#bib1.bibx4

One estimate puts the number of buildings in the world at 2.75 billion.  Can we model them all in Flightgear?

Render, probably yes.  We have a shader-based approach (the BUILDING_LIST STG verb) which scales very well.  It should be possible to use a vector-based data source to write BUILDING_LIST files for simple buildings.

-Stuart

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