Unifying the 2D rendering backend via canvas: Difference between revisions

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


== Background ==
== Background ==
{{cquote|Moving the HUD to use the Canvas would be a great step from my point of view, since it and 2D panels (which I am happy to write the convert for!) are the last places besides the UI which make raw OpenGL calls, and hence would benefit from moving to the Canvas (and thus, to use OSG internally)|[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38629.html  Thomas Geymayer]}}
{{cquote|using the Canvas also for the GUI would give us the advantage of a unified rendering backend for any type of GUI/text rendering and also the ability to use the same widgets everywhere - eg. use them also inside aircrafts for CDU GUIs or other displays... |[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37867.html  Thomas Geymayer]}}
{{cquote|I'm even more convinced now that we should move the 2D panel and HUD rendering over to this approach, since that would get rid of all the legacy OpenGL code  besides the GUI.|[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37868.html James Turner]}}


{{cquote|The long term idea is to eventually port some other 2D elements to this backend (eg the HUD and 2D panels) so they use OSG (and osgText) natively, and hence reduce the amount of C++ code we have for these jobs. (And increase our chances of working with newer OpenGL versions that forbid old style GL calls) Long-term here means 'after 2.8 at least'.|[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37441.html James Turner]}}
{{cquote|The long term idea is to eventually port some other 2D elements to this backend (eg the HUD and 2D panels) so they use OSG (and osgText) natively, and hence reduce the amount of C++ code we have for these jobs. (And increase our chances of working with newer OpenGL versions that forbid old style GL calls) Long-term here means 'after 2.8 at least'.|[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37441.html James Turner]}}
{{cquote|Moving the HUD to use the Canvas would be a great step from my point of view, since it and 2D panels (which I am happy to write the convert for!) are the last places besides the UI which make raw OpenGL calls, and hence would benefit from moving to the Canvas (and thus, to use OSG internally)|[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38629.html James Turner]}}
<references/>


== Background ==
== Background ==

Revision as of 19:11, 5 November 2012


Background

Cquote1.png Moving the HUD to use the Canvas would be a great step from my point of view, since it and 2D panels (which I am happy to write the convert for!) are the last places besides the UI which make raw OpenGL calls, and hence would benefit from moving to the Canvas (and thus, to use OSG internally)
Cquote2.png
Cquote1.png using the Canvas also for the GUI would give us the advantage of a unified rendering backend for any type of GUI/text rendering and also the ability to use the same widgets everywhere - eg. use them also inside aircrafts for CDU GUIs or other displays...
Cquote2.png
Cquote1.png I'm even more convinced now that we should move the 2D panel and HUD rendering over to this approach, since that would get rid of all the legacy OpenGL code besides the GUI.
Cquote2.png
Cquote1.png The long term idea is to eventually port some other 2D elements to this backend (eg the HUD and 2D panels) so they use OSG (and osgText) natively, and hence reduce the amount of C++ code we have for these jobs. (And increase our chances of working with newer OpenGL versions that forbid old style GL calls) Long-term here means 'after 2.8 at least'.
Cquote2.png
Cquote1.png Moving the HUD to use the Canvas would be a great step from my point of view, since it and 2D panels (which I am happy to write the convert for!) are the last places besides the UI which make raw OpenGL calls, and hence would benefit from moving to the Canvas (and thus, to use OSG internally)
Cquote2.png


Background

Hooray: We need to come up with some simple interface, so that the created texture can be used in another system. Specifically, thinking in terms of other od_gauge instruments at the moment: Currently, the problem is that there's the unfortunate trend that more and more advanced aircraft (such as the 787 or the A320neoo) don't use the hard coded C++ instruments (wxradar, tcas or NavDisplay) but instead replicate the instrument in scripting space, because there's more flexibility to customize things. This is because there's currently no simple method to make these two approaches coexist in some sane fashion. In other words, if the Canvas subsystem (or od_gauge itself) had a simple interface to reuse other od_gauge textures, od_gauge instruments could be "chained" together - which would basically make it possible to instantiate a conventional hard coded system (such as the NavDisplay) while still using a scripted Canvas, which could be overlaid over the NavDisplay. For example, the A320neo project could then reuse James C++ code and instantiate a conventional hard-coded NavDisplay, while still implementing custom features using your Canvas subsystem - the final texture output would then combine the results from each chained od_gauge system.

TheTom: I've also been thinking about this. As all od_gauge instruments just render to a texture it would be easy to draw this texture somewhere onto the canvas. But I don't think that would be very flexible as it only allows you to draw on top of the existing image. What I think would be better is to port the hard coded instruments to use the canvas for drawing and therefore enable everyone to modify every little bit of it from eg. Nasal space. On instancing an instrument you would just point it to a node in the property tree and the instrument then puts it's primitives there as child nodes. By this it would be possible to directly point it to a canvas group or also point it to some not canvas node and copy the parts needed manually to a canvas. I don't know how much work it would be to port the existing instruments, but I think this would be the cleanest and by for most flexible approach.
Hooray: Yes, that would be the cleanest and most flexible solution. I think James already mentioned that he's planning to reuse your canvas code in other hard-coded instruments (see the merge request discussion).Instead of issuing raw OpenGL/OSG drawing commands in the subsystem, all of them would need to use your canvas instead.


Planning

The Canvas subsystem is flexible enough to re-implement existing 2D rendering related features, such as the HUD system or the 2D panel system, in scripting space, so that legacy C++ code can be incrementally replaced with a more accessible and more maintainable version in scripting space, i.e. as part of the base package - while ensuring that the 2D rendering backend is increasingly unified, using the Canvas subsystem as the common rendering backend. Once a standalone mode for the canvas system has been implemented, all systems making use of the canvas backend will automatically support standalone (FGPanel-analogous) rendering.

The idea is to provide Nasal wrappers for these systems, which implement the existing behavior using the canvas system, so that the old C++ code can be eventually phased out. In particular, this means that wrappers for the following systems will be added:

Note that the API-requirements will be pretty much identical for GUI widgets and MFD-screens with touch screen functionality, both features will need a way to deal with keyboard/mouse input.


Initially, the main focus will be on providing the infrastructure to enable people to develop widgets entirely in Nasal space. Once that is working, it will be possible to increasingly re-implement native PUI widgets in Canvas/Nasal space, so that PUI usage is increasingly reduced.

To ensure that the Canvas/GUI wrapper is flexible enough, we need to take a look at existing hard coded PUI dialogs/widgets, and make sure that these can be theoretically reimplemented using Canvas/Nasal, and add any missing hooks as required:

This automatically means that PUI callbacks must be forwarded to Nasal, so that they can be implemented as Nasal callbacks.

Also, the Canvas subsystem should be powerful enough to allow re-implementing existing hard-coded od_gauge instruments, such as:

We need to take a look at these instruments and their C++ code, to ensure that the Canvas API is sufficiently customizable to implement these and similar instruments purely in scripting space.

As of 07/2012 the navdb (including airports, runways etc) is fully exposed as part of the NasalPositioned module in $FG_SRC/Scripting: https://gitorious.org/fg/flightgear/blobs/next/src/Scripting/NasalPositioned.cxx