CompositeViewer support: Difference between revisions

Jump to navigation Jump to search

CompositeViewer support (view source)

Revision as of 07:19, 22 August 2021

5,036 bytes removed ,  22 August 2021
m
→‎Motivation
m (→‎Status updates: not specific to avionics)
Line 527: Line 527:


For viewers to share the same node group, you need take care of explicitly sync'ing the FrameStamp between each traversal as otherwise the state of the scene graph can get thrashed between different times.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg19107.html</ref>
For viewers to share the same node group, you need take care of explicitly sync'ing the FrameStamp between each traversal as otherwise the state of the scene graph can get thrashed between different times.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg19107.html</ref>
== Motivation ==
[[File:CompositeViewer 3 cloned views and OSG stats with draw masks.png|thumb|Experimental [[CompositeViewer Support]] showing 3 cloned views, with [[Draw masks]] set (only skydome shown) + OSG stats (~ 120 fps/window) while using [[Howto:Activate multi core and multi GPU support|CullThreadPerCameraDrawThreadPerContext]] <ref>https://forum.flightgear.org/viewtopic.php?f=6&t=38334</ref>]]
Until mid-2020, FlightGear only supported 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 could 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>
Back in 2008, Tim Moore provided a patch ({{Search|keywords=CameraGroup|mode=mailing lists}}) to use the osgViewer class to [[Howto:Configure camera view windows|set up windows, manage the main camera]], etc. <ref>https://sourceforge.net/p/flightgear/mailman/message/19718339/</ref>
However, these windows had to use the same camera group as the main window so could only show the view from the same eye position, though typically at a different angle/offset so that one can emulate things like side windows of a cockpit displayed in a different window or monitor.<ref>https://sourceforge.net/p/flightgear/mailman/message/37059117/</ref>
<!--
There is some tight coupling between the Renderer.cxx and CameraGroup files (now to be found in SimGear<ref>v</ref>) The camera-infos can be configured from XML, eg to additional post-processing stages, but within each CameraInfo the actual osg::Cameras (each of which is really a rendering pass/stage) is determined by one of the buildXXXXX methods.<ref>https://sourceforge.net/p/flightgear/mailman/message/35828189/</ref>
-->
Mathias Fröhlich used the slave camera feature of osgViewer to provide a "video wall" style of multiple displays that was demonstrated at LinuxTag for years. Later on, Tim generalized this to support general monitor arrangements (like a panoramic arc) and general combinations of screens and graphics cards. <ref>https://sourceforge.net/p/flightgear/mailman/message/24811861/</ref>
The default OSG model is that slave cameras are different views offset from a common viewpoint. This is easy to understand when considering  a camera's view matrix, but not necessarily  intuitive when thinking about the projection matrix. Because FG has its own view system we mostly treat the slaves as independent. It seems that most other uses of cameras during rendering -- for example, render to texture cameras for effects -- are best handled by slave cameras with independent views as well.<ref>https://sourceforge.net/p/flightgear/mailman/message/36295606/</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 was not really supported by the previous architecture, neither by the tile cache nor by osgViewer::Viewer. We needed 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 required a change in the previous FlightGear architecture to use a CompositeViewer instead of a single Viewer, but we were contemplating that anyway.<ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17263.html</ref>
The cameras in a camera group don't need to render directly to the screen. They can render to a texture which can be used either in the scene, like in a video screen in the instrument panel, or for distortion correction in a projected or dome environment. <ref>http://sourceforge.net/p/flightgear/mailman/message/19718339/</ref>
Open Scene Graph supports a CompositeViewer object that supports rendering from several widely separated viewpoints, complete with support for multiple terrain pager threads. We could move to CompositeViewer and support simultaneous views from e.g., the tower, AI models, drones, etc.<ref>http://sourceforge.net/p/flightgear/mailman/message/19718339/</ref>
Neither of these were previously supported. We had to start using a different OSG class, CompositeViewer, to support multiple views from independent view points. Our terrain pager needed a complete overhaul to use the [[PagedLOD]] scheme of OSG, and the Flightgear [[View manager]] would need to be aware multiple active views.<ref>=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27134.html</ref>


== Related ==
== Related ==
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/132869"

Navigation menu