I don't disagree that there is exactly the kind of complexity you mentioned (especially CameraGroup stuff and Rembrandt hacks all over the place) - however, like I said - that was all prior to the Canvas days. These days, Tim, Mathias, Fred, Zan and even poweroftwo (osgEarth) would definitely approach their projects differently, by recognizing that they have certain overlapping/shared requirements, and that these could be tackled in a holistic fashion without touching much of the legacy code in question - simply because all of these features are primarily about rendering to a configurable FBO/RTT context.
As a matter of fact, the distorted screen mode is already rendering to a framebuffer - it just isn't used/exposed outside C++ space obviously.
It's very much akin to the introduction of the property tree by David M. - back then it was a novel concept, and people were concerned about using it - e.g. due to performance considerations (they were even using raw pointers to speed up variable access then) - these days, that's a no-brainer obviously. But it's time to recognize that the Canvas system is doing to FlightGear rendering what the property tree did to state/variable sharing - you can now implement arbitrary FBO/RTT rendering without much work, and if something is missing (or too slow), think rendering 3D models or rendering GeoTIFF/DEM heightmaps, it can be added as a new model. Equally, if something is to be shown outside the main fgfs window, it's just a new Canvas placement that needs to be added.
All the concepts are well understood, and the infrastructure is readily there to be picked up - just like David's original work on the property tree subsystem contained support for listeners that weren't really picked up for the better part of a decade, despite tied properties generally considered to be bad thing - which was explicitly communicated by him, too.
These days, you can have an empty OSG/OpenGL-enabled fgfs window up and running without much of an effort, you can disable scenery/terrain, and even the skydome -at which point you could theoretically also implement support for alternate scenery/terrain engines, or even completely alternate renderer schemes akin to Rembrandt.
So this isn't over-simplifying things at all - former core developers like David M. and Erik suggested to do this over a decade ago, it just never materialized - it's only since the introduction and adoption of the Canvas system that this has actually become feasible.
Even Curt himself suggested on various ocassions that the scenery/terrain engine and the renderer infrastructure be treated as a "plugin" akin to the FDMShell machinery that encapsulates the differences between YASim/JSBSim:
viewtopic.php?f=5&t=25081&p=292221&#p292221Someone embarking on a journey to implement a feature like osgEarth, the effects system, Rembrandt without using the Canvas system as the underlying foundation would waste tons of time and sacrifice tons of functionality - the Canvas system literally has become the
property tree for rendering, i.e. there is no conceptual difficulty to tie together all rendering functionality in FlightGear (even conflicting ones like Rembrandt and ALS) using just a handful of concepts (a Canvas, a group, a Canvas element, placements and events)
Thus, if we want to have our cake and eat it, it's time to recognize that there is so much groundwork that has been done by dozens of contributors over the course of the last 2 decades, that we're literally standing on the shoulders of giants - which is to say, there is really no technical hurdle when it comes to porting/re-integrating existing legacy functionality like the GUI, HUD, 2D panels or Rembrandt/osgEarth by going through the Canvas system to serve as the common subsystem providing FBO/RTT support.
And at that point, scenery/TG folks like psadro_gm and others would collaborate despite possibly working on different projects - just like the SGPropertyNode implementation has always been actively maintained by the FlightGear project, simply because it's the foundation, or rather "nervous system", of the whole thing.
Honestly, looking at all the needs for dynamically using RTT, there should hardly be any need for hard-coded FBO use in FlightGear, it could certainly be provided by the Canvas system, which would be extended as needed over time - just like the property node system has been extended, too.
It would no longer matter if you're interested in implementing fancy procedural rendering schemes, Rembrandt-like schemes, a new terrain engine or a completely new renderer - the barrier to entry would be massively lowered, and the code base unified (and hardened !) in the whole process:
http://wiki.flightgear.org/Supporting_m ... _renderersSo there really is no oversimplification here - it's already happening as we're speaking, exactly in line with the impact that the property tree had on the whole FlightGear code base - the only question is how long it is taking until people will recognize that the Canvas system is no necessarily confined to just 2D rendering only, but that it can just well serve as the FBO/RTT provider for arbitrary purposes, and that it can also deal with non-2D use-cases (scenery, 3D models, GeoTIFF) at the mere cost of adding a new Canvas element sub-class - and that its notion of virtual "placements" nicely maps onto the few remaining use-cases not yet covered, as in window management (OS/OSG windows), and streaming to/from a Canvas (think for screen capturing).
It's not exactly rocket science to see what's already going on - the property tree will obviously always remain the nervous system of FlightGear, and given that the Canvas system is merely an abstraction mechanism on top of the property tree, it will continue re-enforce its significance to serve as the primary mechanism to tie rendering components together that primarily need to deal with different FBO/RTTs.