CompositeViewer support: Difference between revisions

Jump to navigation Jump to search
m
update as per request by cgdae
mNo edit summary
m (update as per request by cgdae)
Line 3: Line 3:
-->
-->


== Status ==
{{Out of date}}


{{infobox subsystem
|image      = Fg-cv.png
|name        = CompositeViewer Support
|started    = 07/2020 (early prototype)
|description = Support for multiple independent scene views
|status      = experimental (building, mostly working, buildings missing, supports cloning independent views into distinct windows <ref>https://sourceforge.net/p/flightgear/mailman/message/37086211/</ref> <ref>http://wiki.flightgear.org/CompositeViewer_Support#cite_note-22</ref>) <br/>{{Progressbar|40}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37070203/</ref>
|developers  = Julian Smith<ref>https://sourceforge.net/p/flightgear/mailman/message/37062319/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/37077854/</ref>
|changelog = https://sourceforge.net/u/cgdae/profile/feed.rss, https://sourceforge.net/u/cgdae/flightgear/ci/CompositeViewer/tree/
<!--
|topic-fg= https://sourceforge.net/u/cgdae/flightgear/ci/CompositeViewer
|topic-sg= https://sourceforge.net/u/cgdae/simgear/ci/CompositeViewer
-->
<!--
|folders =
* {{flightgear file|src/Viewer}}
* {{simgear file|simgear/scene/viewer}}
* {{fgdata file|Compositor}}
-->
}}
{{Rendering}}
<!--
{{Multicore}}
-->
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>
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 have to use the same camera group as the main window so can 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'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>
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 are supported at the present time, but it would be a good project. We would have to start using a different OSG class, CompositeViewer, to support multiple views from independent view points. Our terrain pager would need 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>
== Status ==
{{Note|While it's certainly possible to have a look at the changes <ref>https://sourceforge.net/p/flightgear/mailman/message/37077854/</ref> and understand how things are working, the code isn't really ready for review and push yet - there's still loads of debug diagnostics and a few dead-ends in there. Jules is hoping to be able to address some of these over the next few days.<ref>https://sourceforge.net/p/flightgear/mailman/message/37077148/</ref>
{{Note|While it's certainly possible to have a look at the changes <ref>https://sourceforge.net/p/flightgear/mailman/message/37077854/</ref> and understand how things are working, the code isn't really ready for review and push yet - there's still loads of debug diagnostics and a few dead-ends in there. Jules is hoping to be able to address some of these over the next few days.<ref>https://sourceforge.net/p/flightgear/mailman/message/37077148/</ref>
In other words: No one is claiming CompositeViewer support is anywhere near being ready to be  enabled by default - there are lots of issues to sort out, at the moment chiefly how to get scenery to show up in cloned views and interact with scenery caching properly etc.  
In other words: No one is claiming CompositeViewer support is anywhere near being ready to be  enabled by default - there are lots of issues to sort out, at the moment chiefly how to get scenery to show up in cloned views and interact with scenery caching properly etc.  
Line 112: Line 60:
|}
|}


{{infobox subsystem
|image      = Fg-cv.png
|name        = CompositeViewer Support
|started    = 07/2020 (early prototype)
|description = Support for multiple independent scene views
|status      = experimental (building, mostly working, buildings missing, supports cloning independent views into distinct windows <ref>https://sourceforge.net/p/flightgear/mailman/message/37086211/</ref> <ref>http://wiki.flightgear.org/CompositeViewer_Support#cite_note-22</ref>) <br/>{{Progressbar|40}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37070203/</ref>
|developers  = Julian Smith<ref>https://sourceforge.net/p/flightgear/mailman/message/37062319/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/37077854/</ref>
|changelog = https://sourceforge.net/u/cgdae/profile/feed.rss, https://sourceforge.net/u/cgdae/flightgear/ci/CompositeViewer/tree/
<!--
|topic-fg= https://sourceforge.net/u/cgdae/flightgear/ci/CompositeViewer
|topic-sg= https://sourceforge.net/u/cgdae/simgear/ci/CompositeViewer
-->
<!--
|folders =
* {{flightgear file|src/Viewer}}
* {{simgear file|simgear/scene/viewer}}
* {{fgdata file|Compositor}}
-->
}}
{{Rendering}}
<!--
{{Multicore}}
-->
== History ==
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>
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 have to use the same camera group as the main window so can 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'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>
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 are supported at the present time, but it would be a good project. We would have to start using a different OSG class, CompositeViewer, to support multiple views from independent view points. Our terrain pager would need 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>


=== Open Questions ===
=== Open Questions ===

Navigation menu