Over the years, one of the most cited reasons for holding back FlightGear vs migrating/adopting OSG fully was actually lack of PagedLOD adoption (which I do realize is no longer the case), but also migrating to a CompositeViewer based renderer (which I do know you are aware of due to your previous work involving a custom Canvas view element, porting/generalizing the view manager, and your comments in the context of migrating the CameraGroup infrastructure for work with the Compositor)
But like you're alluding to, as long as a legacy feature is optional and not automatically running in the main loop, it's probably a no-brainer.
With the ongoing adoption of the compositor based approach, and some additional hooks/integration with effects/shaders + canvas, it's increasingly likely that this will have a massive impact on other rendering features, e.g. all the autogen stuff (think PixelCity) we've been talking about for years, could all of a sudden be implemented by fgdata contributors, simply by using a combination of XML, effects, shaders and some Nasal/Canvas adapters.
Also, we've seen so many attempts at coming with a new/improved scenery/terrain LOD scheme, as well as ideas to support other planets (the sky no longer is the limit ...
)
Which is to say, there still is quite a bit of leeway to be had just by making existing legacy functionality optional, and going with OSG for quite some time.
Of course, it depends on your goals - but as long as osgviewer/fgviewer can provide significantly better performance when rendering a 3D model/terrain mesh, there is also optimization potential left, even without adopting a totally novel scene graph implenentation.
That being said, in the aftermath of the OSG migration (~2006) Mathias has actually been promoting encapsulating OSG specifics, which is something that he repeatedly discussed with other senior contributors like Tim, who didn't quite see his point at the time - but Mathias was definitely foreseeing the need to eventually migrate again, and didn't want to have to deal with another plate of spaghetti code
https://www.mail-archive.com/flightgear ... 22638.htmlTim Moore wrote:Mathias Fröhlich wrote:from my point of view. I would prefer to have these.
The reason is to have something self contained here.
Sure we already rely on osg at many places. But if I build an aplication on
simgear, I hope to have simgear classes there. SGProperties are simgear
classes, and if you use the property system you may not want to rely on osg.
... also from my past experience switching to an other scenegraph, I would
prefer to see no osg::.. references at all in flightgear - except some few
viewer related stuff. But the simulation part of FlightGear should not need to
know that the viewer runs on osg/OpenGL.
So looking at SimGear as a utility library for simulation applications, this
make sense from my point of view ...
So, even if you will need some more glue code, I would prefer to avoid osg
classes in simgears parts that are not scenegraph related.
Seriously, I didn't realize that reducing dependencies on OSG in simgear is a
design goal. That's fine, but I would really prefer to not think about whether
I need to pass an SGVec3d or an osg::Vec3d to a function, or whether a smart
pointer should be an osg::ref_ptr or an SGSharedPtr or...
Tim
And since you're currently in the process of establishing the future of FlightGear's rendering architecture, maybe some food for thought for you ?