|
From: Gerard K. <ge...@ge...> - 2026-06-02 20:23:57
|
Thanks all! Happy about all the responses. I've read them all and have
replied to some of them below.
It seems that most people agree that AI code is acceptable as long as
the submitter reviews it well, which I certainly intend to do.
The other main points seem to be about integration. I could definitely
use some pointers on that.
* If this gets into FlightGear, how would that look like?
* Would this be a toggle you enable in the settings, and then it loads
with this terrain renderer as long as there is coverage?
* What happens when you fly out of this area? Do we fallback to low
res satellite images or to WS3.0?
* How should this handle time, and simulated weather?
* Is it possible to use certain parts of existing terrain renderers
(e.g. for lights) in combination with this?
* Would the data providers even be happy with us just loading this
data and putting it into a flightsim? I can reach out to them.
For now I'll play around with this a bit, improve the code, and work on
some more areas. I've added some screenshots of the Alps to
https://gerardkrol.nl/flightgear/
On 02-06-2026 04:52, Curtis Olson wrote:
> 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.) :-)
Thanks! Yeah it will be a couple of decades before there is good enough
ortho/DSM data of the entire world for this to work everywhere, so this
will have to fit in with another system. This still needs lights at
night & PAPI lights anyway.
On 02-06-2026 11:18, Stuart Buchanan wrote:
> 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.
Fully agree, I'll definitely review the code. I'm an experienced code
reviewer and I'll definitely not put up a merge request with code I
would not vouch for.
> 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.
Loading WMTS maps is not that hard, just fiddly. You need to get the
coordinate system correct, load the right level and make sure the
texture doesn't show up upside down. In my code I'm making sure the WMTS
aligns exactly with the quadtree, which simplifies things a lot. Using
this technique in combination with another terrain renderer should
certainly be possible.
On 02-06-2026 12:24, James Hogan via Flightgear-devel wrote:
> The high res (1m or better) lidar data from the UK environment agency, that I've long wanted in FG but it doesn't look convenient to stream directly, have both DSM (surface) and DTM (terrain), theoretically allowing vegetation and buildings to be fairly directly determined including their height above the terrain...
Interesting. I found a WCS source (which I'm using for NL), at 1m
resolution. So if that one works then combined with a WMTS (or WMS) map
it would maybe take only 1-2 hours to plug this in. I'm currently
working on Tirol (Austria) but I might give this a try soon!
https://environment.data.gov.uk/dataset/df4e3ec3-315e-48aa-aaaf-b5ae74d7b2bb
On 02-06-2026 15:56, Patrick Callahan wrote:
> 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?
Yeah it should be possible to 'sharpen' the buildings somewhat, but
you're also limited by the density of the heightmap mesh and the DSM
source you're using. Or, as you mentioned, you could use real meshes
from OSM or governments. Generally I think a top down aerial photo does
not have enough information to make buildings look good when viewed from
the side whatever you do. If anyone can find free/open 45 degree photo's
we could project these on them and it would look much better.
> Take a look at https://kartta.hel.fi/?setlanguage=en and click the
> 2d/3d button on the right. Zoom in and out on Helsinki.
These are really cool. Google Earth also has some nice ones of selected
cities. I believe these are made using photogrammetry from oblique (45
degree) photo's. So a lot of preprocessing. Would not surprise me if
data like this would start appearing as 3D meshes for certain cities. I
do like the colors of these things a bit less than with a nice sunny
aerial photo though. You'd have to put some good lighting on them.
On 02-06-2026 18:03, Stuart Buchanan wrote:
> I understand that WMTS supports LoD natively. So WS3.0 would simply
> request a WMTS ortho tile at an LoD appropriate for the WS3.0 LoD
> level. I anticipate that the tile scheme won't match perfectly, one
> might have to load multiple tiles, but that should be manageable.
Yeah it's not really a problem to request multiple tiles and combine
them. I've had that in one of my prototype phases when I had a
misaligned heightmap. The overhead is quite limited as you can just
cache the 'extra' tiles and will probably use most of them.
> Making this up as I go along: Yes - the idea would be that the ortho
> is requested (from disk/http) as FlightGear loads the WS3.0 scenery
> tiles. This happens in a bunch of separate threads, and would only
> replace the existing visible tile when it is complete. So from a user
> perspective all that would happen is that scenery would update a bit
> slower the first time as we download the ortho.
Yeah not problem at all. The hardest thing is figuring out the
coordinate systems as most countries use their own for their internal needs.
Regards,
Gerard
|