Satellite/Photo Scenery?

[Thorsten]

Oh, and I would very much appreciate if we could drop 'the painter' designation - I have a name, kindly use it - you probably also don't want to be called 'the troll' here, right?

[Hooray]

FWIW, poweroftwo (Jeff) mentioned on seversal occasions that the previously mentioned issues are well-known, i.e. osgEarth de-facto being a "black box" that becomes increasingly difficult to integrate with existing features that it is unaware of, due to hard-coded assumptions, or due to the underlying nature of the data used to create the environment, and this applies especially to anything involving our vector data (roads, railways, rivers etc) and obviously buildings (3D models or procedurally created stuff) - at the time, Jeff stated that he ran into a number of issues integrating osgEarth with our existing effects/shader framework, which he considered unfortunate, because he'd been wanting to use FlightGear's unprecedented weather engine/visuals (namely, advanced weather).

All of this is off the top of my head, so to be taken with a grain of salt, but I do recall that Jeff was in touch with the folks working on osgEarth (Pelican Mapping) and that they stated, they'd increasingly work towards making osgEarth much less of a black-box (over time).

Then again, I don't know how much of this materialized or not, but even under perfect circumstances, a flight simulator like fgfs would definitely present huge challenges - many of which can already be seen when using google maps/google earth and comparing it to real life data, there are many obvious shortcomings.

Finally, I still do think that it would be a good idea to provide an osgEarth-enabled build/mode, even if just to provide/maintain options for the future - especially in the light of the MapServer/TerraSync situation a while ago, i.e. purely froma redundancy standpoint, as per Thorsten's comment about Rembrandt vs. ALS performance:

ALS aircraft lights

Anyway, to each his own - options are good.

Supporting not just a single FDM, or operating system/computer architecture, has obviously served fgfs rather well, it would seem rather prudent to keep that in mind whenever new, optional, features are offered to the project, especially if these come not just in the form of patches/topic branches, but also alongside someone volunteering to handle integrating/maintaining and developing such functionality in the time to come, especially if someone is willing to develop their optional feature as part of a topic branch or cmake build option until it is ready for "prime time".

Finally, it's worth keeping in mind, with fgfs all of us are standing on the shoulders of giants, i.e. it's good for the project to have many pillars (read: options) - and it's rather unfortunate to see whenever people feel left-out-of-the-loop, especially after spending substantial time working on a new set of features.

Compared to the discussion revolving around the optional dependency on osgEarth, optionally requiring Qt5/QQ2 and a more recent version of OSG seems to have been a piece of cake.