Difference between revisions of "Howto:Create a 2D drawing API for FlightGear"

From FlightGear wiki
Jump to: navigation, search
(Switch to {{fg src file}}, {{flightgear source}}, and {{gitorious merge request}}to fix the broken Gitorious links.)
m (Afd)
Line 1: Line 1:
{{Afd|reason=obsolete and addressed by the creation of the canvas system, 8+ years ago.}}
{{Affected by Canvas}}
{{Affected by Canvas}}

Latest revision as of 06:09, 25 November 2020

This has been nominated for deletion. To discuss it, please visit the talk page.

Do not remove this tag until the discussion is closed.

Reason for the nomination: obsolete and addressed by the creation of the canvas system, 8+ years ago.

IMPORTANT: Some, and possibly most, of the features/ideas discussed here are likely to be affected, and possibly even deprecated, by the ongoing work on providing a property tree-based 2D drawing API accessible from Nasal using the new Canvas system available since FlightGear 2.80 (08/2012). Please see: Canvas 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 Canvas subforum This is a link to the FlightGear forum.. Anything related to Canvas Core Development should be discussed first of all with TheTom and Zakalawe. Nasal-space frameworks are being maintained by Philosopher and Hooray currently. talk page.



Come up with the technical requirements and document the exact C++ steps required to make a 2D drawing API accessible to Nasal scripts.

Status (06/2013)

Initial support for the new Canvas 2D rendering API is available in FlightGear 2.8. More recent versions (beyond 2.11+) provide lots enhancements. This article is purely kept for reference here now, as it may help future developers doing similar things.

Creating a new instrument

Additional info

See Howto:Use a Camera View in an Instrument#osgViewer::CompositeViewer

In 2008, FlightGear core developer Tim Moore wrote this:

$FG_SRC/src/Cockpit/wxradar.cxx and $FG_SRC/src/Cockpit/od_gauge.cxx are the existing examples we have of a custom glass instrument. A more recent addition is available in $FG_SRC/src/Cockpit/NavDisplay.cxx.

The weather radar does work in "FlightGear OSG"; there isn't any weather yet, but it can show other aircraft traffic and is the basis for the ATC radar. $FG_SRC/src/Cockpit/od_gauge.cxx uses the method that would be used for any glass instrument: an osg::Camera that is bound to an off-screen render target, i.e a texture. The texture can then be used anywhere in the scene.

You can integrate arbitrary OpenGL code with an OSG application. It is most friendly to setup and change all OpenGL state using OSG's StateSet mechanism, but even that is not necessary. We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code.

(There is a new OSG pluggin that requires librsvg in OSG 2.6.0 RC1.)

If a vector description of instruments is the way to go, then you should look at using SVG with OpenGL and OSG. The big player here is cairo+glitz, but the last time I looked at this it was hard, perhaps impossible, to coax glitz to draw into an OpenGL context that it had not created. Perhaps this has been solved. Another library is svgl at svgl.sourceforge.net, but I have no idea if it is still alive. Any solution that renders to memory using the CPU is going to be too slow, IMHO.

A moving map is a different beast. It would make sense to implement that as a scene graph in its own right with its own pager. That would require a change in current fg architecture to use a CompositeViewer instead of a single Viewer, but we're contemplating that anyway.