Canvas popout windows

From FlightGear wiki
Revision as of 15:28, 10 July 2020 by Hooray (talk | contribs) (→‎Problem: https://sourceforge.net/p/flightgear/mailman/message/37058207/)
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.

Motivation

Some users have been wondering if it is possible that Canvas panels can be dragged to another monitor and or be resized if they are not modelled in a particular plane. [1]

one of the big problems of the FlightGear GUI is that it is "inside" the only and one main window. There is no possibility to have a separate window to not cover the main content, the scenery and the cockpit? This would make the GUI much more practical. [2]

It would be useful if the UI can be trivially hosted as an OpenGL overlay *or* a pop-out window, to give people the flexibility to move the UI to a second screen.[3]

Would it be possible to make the Canvas Windows leave the FlightGear borderspace? Like in P3D, I can right click a window and click “Undock Window”, which then gives it its own system title bar and then I can put it on other monitors.

If added, this could make 2D panels via Canvas a lot of useful! I can have the sim on one screen, and a radio stack on another, for example, to easily switch radios. Or a lighting panel.[4]


What I guess you want here, is to start creating the kind of GPS Ui that would be found in GA aircraft - for example a Garmin GNS 480 series or the more modern equivalent. This could be done as as a Nasal add-on so it could added as a variant into many GA aircraft including the C172, and would give you all the route-manager features and display.

(It could also be a pop-out Canvas window)[5]

Background

The issue is how to get fgfs to open a separate window with its own view/camera setup?

For example, [...] to have Tower View AGL active in a separate window (perhaps on a multiplayer aircraft), while the main window shows the view from the user aircraft's cockpit.

Such a window will need its own CameraGroup; would it also need its own FGRenderer or would it share the one used by the main window?

It would be enough to just being able to have a separate window with an empty OSG state that can then be filled in by writing new Camera/view code.[6]

The scene root is a member of the Viewer. A slave camera -- whose own pose in the scene is either relative to the main camera or completely independent -- can be configured to render the main scene or a completely different scene graph. For example, the camera that does Canvas rendering is set up like that.[7]


Currently, the GUI can only be placed inside one view/window (see Docs/README.multiscreen) but it would be nice to be able to move windows between views.[8]

Problem

currently not possible in FG, although OSG has the perfect tool for the job: CompositeViewer. Some info and past discussions on the topic can be found here CompositeViewer Support.

As mentioned, each view would require another CameraGroup, the problem is that currently the entire FG codebase assumes that the CameraGroup is a singleton. If you manage to solve that, it would just be a matter of defining some kind of configuration scheme for the new CameraGroups and instantiate them on startup (preferably on FGRenderer). You wouldn't have to deal with the internals of CameraGroup as the rendering pipeline of each view is managed by a Compositor.[9]

It's possible to do, but it's definitely not trivial. There are two showstoppers:[10]

  • Canvas uses nested cameras, not viewer-level slave cameras. You can only assign another GraphicsContext (another window) to slave cameras as nested cameras inherit their GraphicsContext from the main viewer camera. I think Tim Moore mentioned somewhere that he had a patch to move Canvas to slave cameras [11]
  • CameraGroup hasn't been thought out from the beginning to support dynamic creation of windows. At startup the property tree in /sim/rendering/camera-group is read and the specified windows/cameras are created. I guess supporting this would require some architectural changes to CameraGroup.


Another idea previously mentioned is to fix up WindowBuilder which can already do multiple windows? (with an XMl driven UI, though : that’s the part that is missing to make it useful at runtime), i.e. extending WindowBuidler to allow changes at runtime might be a better solution [...] because this will keep existing multi-window / multi-view setups working. [12]

Implementation

While cameras can be attached to the scene root (e.g., the cameras that render Canvas objects), the viewer's cameras are outside of the main scene graph.[13]

This can be solved by using multiple osg windows to contain whatever GUI solution we go with - canvas, osgWidget or PUI-port.[14] The current window manager registers itself to the main viewer and subscribes on osgGA events, so the canvas has no dependencies on the old system.[15]


The default OSG model is that slave cameras are different views offset from a common viewpoint. [...] Because FG has its own view system we mostly treat the slaves as independent. I think 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. [16]

See also

References

References