CompositeViewer support: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 106: Line 106:


== Implementation ==
== Implementation ==
{{See also|Canvas View Camera Element}}


{{FGCquote
{{FGCquote
Line 152: Line 153:
   }}
   }}
}}
}}


== Related ==
== Related ==

Revision as of 20:18, 8 July 2020

IMPORTANT: Some, and possibly most, of the features/ideas discussed below are likely to be affected, and possibly even deprecated, by the ongoing work on providing a property tree-configurable rendering pipeline accessible via XML using the new Compositor system available since FlightGear 2020.3 (11/2020): The main rendering pipeline (on next at least) is now the Compositor using ALS. The "classical renderer" and "Project Rembrandt" have been superseded. From the perspective of creating regional material definitions, you can just develop against ALS and you will be fine.[1]

Please see: Post FlightGear 2020.2 LTS changes for further information You are advised not to start working on anything directly related to this without first discussing/coordinating your ideas with other FlightGear contributors using the FlightGear developers mailing list or the Effects & Shaders subforum This is a link to the FlightGear forum.. talk page.

Compositor logo.png


Cquote1.png 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.
— Tim Moore (2008-06-26). [Flightgear-devel] RFC: changes to views and cameras.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— Tim Moore (2008-06-26). [Flightgear-devel] RFC: changes to views and cameras.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.[2]
— Tim Moore
Cquote2.png
Cquote1.png 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 preferences.xml, they all are relative to the current view in FG (i.e. cockpit, tower...). I think it is possible to define a "static" view, but most likely that is not of use, it is only used on some panels I think.
— Zan (Dec 29th, 2011). Re: Request for Multi-Display feature.
(powered by Instant-Cquotes)
Cquote2.png


Cameras

Note  There is a related patch available at https://forum.flightgear.org/viewtopic.php?f=71&t=23929#p317448

Background

Cquote1.png I have to create two master cameras to controls the two different views in two different scene rendering dynamically.


but flightgear only using viewer class . This is createing one master camera no.of slave cameras. but i need CompositeViewer class. how to use CompositeViewer class in flightgear and how to render through CompositeViewer class.


Cquote2.png


Cquote1.png What i want to achieve: Multiple views of the same scene . Lets call them View1 and View2(they may be on 2 separate screens). There should be only one instance of flightgear running. I should be able to have "View1 = Cockpit View & View2 = Chase View" or "View1 = Helicopter View & View2 = Cockpit View" or any other such combination of views. I am using FlightGear 2.0.0 I should be able to switch the view in each viewport without affecting the view in the other view port. i.e i should be able to double right click and change the view on each display with the mouse without affecting the view in the other display. README.multiscreen in the FlightGear documentation says its possible to create a master camera and a slave camera that is offset from the master camera. BUT I want 2 master cameras that can switch to any view at any time.[3]
Cquote2.png
Cquote1.png I have just been trying out the multiple screen feature in FG. I found that the GUI camera (including the menu bar, hud and 2D panel) appears in only

one of the windows. Is there any way I can make the GUI to appear in all the windows? Actually I want to be able to view the hud and 2D panel in all the windows.

Also when I change the view in any one of the windows, the view changes in the other windows as well. Is it possible to make the windows independent of each other. I want to display the cockpit in one window at all times, in the second window I want to be able to shuttle between helicopter / chase or model views.

Also I have observed that in the second screen where I'm displaying lets say the Helicopter view the aircraft remains static while the environment moves. This is because the cockpit view in my Master screen is defined as 'lookfrom'. Can I define 'lookfrom' for one screen and 'lookat' for the

other screen.[4]
— Kavya Meyyappan
Cquote2.png
Cquote1.png I think you have just summarized all the limitations of the FlightGear multi-camera/view/display system. Tim Moore is the person who developed

this feature (nothing existed before his efforts) and maybe he can offer more insight. I know that in the case of menus, hud, 2d instrument panels,

there would need to be some significant code restructuring to allow these to be displayed on other windows.[5]
— Curtis Olson
Cquote2.png
Cquote1.png there's a limitation in Plib that forces the GUI to be drawn on one window.[6]
— Tim Moore
Cquote2.png
Cquote1.png That would require a change in current fg architecture to use a CompositeViewer instead of a single Viewer, but we're contemplating that anyway.[7]
— Tim Moore
Cquote2.png
Cquote1.png 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.[8]
— Tim Moore
Cquote2.png
Cquote1.png 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.[9]
— Tim Moore
Cquote2.png
Cquote1.png Good thing to have!!! Just still support graphics context on different screens/displays too ...[10]
— Mathias Fröhlich
Cquote2.png
Cquote1.png FG only supports one view position at a time, right? Multiple 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...[11]
— ThorstenB
Cquote2.png
Cquote1.png Yes, 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.[12]
— Tim Moore
Cquote2.png
Cquote1.png this also raises the question of reproducible clouds. If we have multiple independent viewers in the future, we need to draw the same clouds on

each with a bare minimum of communication. So, what is needed to generate the exactly same cloud. May be an initial seed for the random number generator, a position and a size? We may need to identify such a set of parameters and may be we should have a peudo loader for osg producing this kind of clouds from these parameters. The you would be able to load and use these clouds from fgviewer and see isolated statistics about the draw/cull whatever steps. This

might also help in understanding what is going on.[13]
— Mathias Fröhlich
Cquote2.png

Implementation

Cquote1.png Most of the required PagedLOD work (involving the tile manager in SimGear) has been recently completed - so there isn't too much missing in terms of refactoring on the SG side - primarily, you'll want to look at the "view manager" in $FG_SRC/Viewer and identify "singleton" use-cases there.
Cquote2.png
Cquote1.png First of all, you'll have to replace the existing viewer with a single CompositeViewer - FlightGear's view manager is property-controlled, and there's currently the hard-coded assumption that there's only ever a single active MAIN view (other supported views are SLAVE views, i.e. slaved to the main view).


you'll find dozens of references to something like globals->get_view_mgr() in quite a few places demonstrating the underlying assumption.
Personally, I would just change the function's signature and add an optional index, defaulting it to 0 - that way, you won't have to touch all the places wanting to have the single main view.

Once that is working, it comes down to trial & error, i.e. testing multiple independent viewers, each having their own instance/access to the tile manager - the work itself is well understood and pretty straightforward, and pretty much all core developers agree that this is a worthwhile thing to aim for - it's just not currently being prioritized or being worked on by anybody else as far as I am aware.


Cquote2.png
Cquote1.png If you're interested in seriously pursuing this, you'll want to look at the CompositeViewer example in the OSG source tree, and read up on discussions about CompositeViewer coding on the OSG list.

For the SG/FG side of things, the aforementioned wiki articles should be pretty comprehensive already - and then you'll probably want to get in touch with fellow FG developers using the FG developers mailing list.


Cquote2.png
Cquote1.png Depending on your degree of familiarity with OpenGL/OSG coding, you could have a basic version of this running within 3-4 weekends - but I guess it might take at least another 4-6 weeks of spare time coding to actually tease out all the hard-coded assumptions about having a single main view only.


The other issue is getting your work reviewed, i.e. committed upstream, which is known to be a particularly long, tedious and painful process - especially for anything non-trivial that may possibly break critical parts of the simulator - which is why it's a good idea to start networking early on, i.e. by discussing this work way ahead of time and getting people involved to provide feedback - which may involve working through a gitorious topic branch.

The underlying PagedLOD in SimGear work is generally understood to be vital for other parts of the simulator, so anything related to this should also be appreciated.


Cquote2.png

Related

References

References
  1. https://sourceforge.net/p/flightgear/mailman/message/37758886/
  2. Tim Moore (Sat, 20 Mar 2010 01:42:31 -0700). Re: [Flightgear-devel] Help needed with multi-screen.
  3.  (). Multiple views without slaving to master camera.
  4. Kavya Meyyappan (Fri, 19 Mar 2010 03:31:50 -0700). [Flightgear-devel] Help needed with multi-screen.
  5. Curtis Olson (Fri, 19 Mar 2010 08:36:22 -0700). Re: [Flightgear-devel] Help needed with multi-screen.
  6. Tim Moore (Sat, 20 Mar 2010 01:42:31 -0700). Re: [Flightgear-devel] Help needed with multi-screen.
  7. Tim Moore (Mon, 04 Aug 2008 02:43:52 -0700). Re: [Flightgear-devel] Cockpit displays (rendering, modelling).
  8. Tim Moore (Thu, 26 Jun 2008 03:53:05 -0700). [Flightgear-devel] RFC: changes to views and cameras.
  9. Tim Moore (Thu, 26 Jun 2008 03:53:05 -0700). [Flightgear-devel] RFC: changes to views and cameras.
  10. Mathias Fröhlich (Sat, 28 Jun 2008 00:05:19 -0700). Re: [Flightgear-devel] RFC: changes to views and cameras.
  11. ThorstenB (Sun, 19 Sep 2010 07:41:13 -0700). Re: [Flightgear-devel] Disappearing scenery.
  12. Tim Moore (Sun, 19 Sep 2010 11:39:32 -0700). Re: [Flightgear-devel] Disappearing scenery.
  13. Mathias Fröhlich (Wed, 07 Dec 2011 22:16:45 -0800). Re: [Flightgear-devel] Trying to get more performance out of the 3D clouds!.