FlightGear Newsletter May 2012: Difference between revisions

Canvas
(Canvas)
Line 22: Line 22:
[[File:Cessna 172P Canvas Demo.png|380px|thumb|Demonstration of the new Canvas drawing API on the Cessna 172P.]]
[[File:Cessna 172P Canvas Demo.png|380px|thumb|Demonstration of the new Canvas drawing API on the Cessna 172P.]]


Tom is currently working on a 2D drawing API. The basic idea is to draw arbitrary 2D shapes and text to a texture and place this texture on some model in the scene (eg. display, HUD,...). This so called canvas should be controlled only by using the property tree.
Tom is currently working on a 2D drawing API. The basic idea is to draw arbitrary 2D shapes and text to a texture and place it somewhere in the scene, like for example on virtual displays or as a HUD. This so called canvas should be controlled only by using the property tree, and will among other advantages, greatly simplify the creation of complex instruments which can be found in todays glass cockpits.


Currently it is possible to draw text, transform it, change style and all of this through the property tree. I have also added an experimental
Currently it is possible to draw text, transform it, change it's style (color, background, font, etc.) and all of this through the property tree. To simplify the usage also exists an experimental Nasal API which provides an object orientated wrapper around the property tree interface to the canvas.
Nasal API which provides an object orientated wrapper around the property tree interface to the canvas.


The code is already include into flightgear/next, but some fixes and the Nasal API are waiting to be merged into flightgear and fgdate respectively.
The code is available in the latest development versions of FlightGear and Tom has already tested many scenarios, but it would be great if you can try it out on your own and report bugs or provide some feedback.


Tom has already tested many scenarios but it would be great if you can try it out on your own and report bugs or provide some feedback :)
The long term (after FlightGear 2.8) 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 never OpenGL versions that forbid old style GL calls).
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 never OpenGL versions that forbid old style GL calls)  
Long-term here means 'after 2.8 at least'.


In the meantime the more testing and feedback we can get the better. In particular this system should offer a much more efficient way to build CDU  
In the meantime the more testing and feedback we can get the better. In particular this system should offer a much more efficient way to build CDU  
interfaces than many text animations, but as always it needs people to experiment and report what features are missing to make their life easier.
interfaces than many text animations, but as always it needs people to experiment and report what features are missing to make their life easier. The video below shows what can be achieved without using tons of predefined text animations, but instead just some Nasal code.


Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will
As this system stablizes creating a 'fgcanvas' client analogous to [[FGPanel|'fgpanel']] should be doable too, which will allow to run a canvas in a standalone application.
require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend.


Please see [[Canvas Properties]] for more details.
Please see [[Canvas Properties]] for more details.
166

edits