FlightGear Newsletter July 2020: Difference between revisions

Jump to navigation Jump to search

FlightGear Newsletter July 2020 (view source)

Revision as of 13:01, 1 August 2020

600 bytes added ,  1 August 2020
m
→‎Early CompositeViewer Experiments: clean up + add intro
No edit summary
m (→‎Early CompositeViewer Experiments: clean up + add intro)
Line 35: Line 35:
[[File:Fg-cv.png|thumb|Julian just made some progress on CompositeViewer integration actually.He set things up so that one can 'clone' the current view using akey-press. This creates a new top-level view window with its own copyof the current view's camera projection matrix etc. The view is addedto the CompositeViewer so it sees the same scene.For now at least, cloned views' projection matrices don't change so thecloned views are completely independent from movement of the aircraft orchanges to the main view. Eventually he'd like to make them behave moredynamically, e.g. follow the aircraft if cloned from Helicopter View.At the moment most of the scenery doesn't show up and the backgroundcolours are wrong, but this screen shot shows it working]]
[[File:Fg-cv.png|thumb|Julian just made some progress on CompositeViewer integration actually.He set things up so that one can 'clone' the current view using akey-press. This creates a new top-level view window with its own copyof the current view's camera projection matrix etc. The view is addedto the CompositeViewer so it sees the same scene.For now at least, cloned views' projection matrices don't change so thecloned views are completely independent from movement of the aircraft orchanges to the main view. Eventually he'd like to make them behave moredynamically, e.g. follow the aircraft if cloned from Helicopter View.At the moment most of the scenery doesn't show up and the backgroundcolours are wrong, but this screen shot shows it working]]


Julian Smith reported some  success by crudely changing flightgear's FGRenderer's osgViewer::Viewer to an osgViewer::CompositeViewer with a single osgViewer::View, and patching up all the calling code so it compiles.
For the time being, FlightGear only supports one view position at a time. Multiple independent view positions (e.g. one screen for the tower view and a second screen for the plane) would complicate a "locked to cache" flag quite a lot...<ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg28864.html</ref>.
 
Aircraft can define their own views and so on. But only one view can be active at a time. So no matter how many windows and cameras you define in [[Defaults.xml]], they all are relative to the current view in FG (i.e. cockpit, tower...). <ref>http://forum.flightgear.org/viewtopic.php?p=146136#p146136</ref>
 
People requiring multiple independent views on the same scenery, e.g. cockpit and tower view [...] these each need their own camera groups and so require OSG's CompositeViewer.<ref>https://sourceforge.net/p/flightgear/mailman/message/37059117/</ref>
 
And that's not really supported by the current architecture, neither by the tile cache nor by osgViewer::Viewer. We would need to move to a CompositeViewer model, which supports several scene graphs, and rely completely on the osg database paging machinery.<ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg28869.html</ref>
 
That would require a change in current fg architecture to use a CompositeViewer instead of a single Viewer, but we're contemplating that anyway.<ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17263.html</ref>
 
 
Julian Smith reported some  success by changing flightgear's FGRenderer's osgViewer::Viewer to an osgViewer::CompositeViewer with a single osgViewer::View, and patching up all the calling code so it compiles.


It all builds ok, and he now got fgfs mostly working with CompositeViewer and the usual single View.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/</ref>
It all builds ok, and he now got fgfs mostly working with CompositeViewer and the usual single View.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/</ref>
Line 44: Line 55:


To execute the patched binary with the compositeviewer enabled, use: <code>fgfs  --composite-viewer=1</code> <ref>https://sourceforge.net/u/cgdae/flightgear/ci/059cf073c74d43a57c11f363cae6c9271772d869</ref>
To execute the patched binary with the compositeviewer enabled, use: <code>fgfs  --composite-viewer=1</code> <ref>https://sourceforge.net/u/cgdae/flightgear/ci/059cf073c74d43a57c11f363cae6c9271772d869</ref>
Unfortunately the property system seemed to be not set up early enough to read in FGRenderer's constructor so we do a few calls of fgGetNode("/sim/composite_viewer", true)->getBoolValue() at runtime. Julian suspects they aren't called very frequently, in which case this branch (minus the diagnostics changes probably) might be ok to push to next at
some point, so that it's easier to test/investigate things.<ref>https://sourceforge.net/p/flightgear/mailman/message/37062319/</ref>
The previous problem with loading scenery was caused by code using the single View's getFrameStamp(), which appears to be never updated and always has _frameNumber=0. We need to use the CompositeViewer's getFrameStamp() instead.
For some reason buildings don't appear, but basic ground scenery now loads so fgfs progresses to loading the fdm etc and one can fly the aircraft as normal.


== New software tools and projects ==
== New software tools and projects ==
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/126690"

Navigation menu