20,741
edits
Canvas properties: Difference between revisions
Jump to navigation
Jump to search
m
→Status 05/2013
m (no longer WIP) |
m (→Status 05/2013) |
||
| Line 6: | Line 6: | ||
A property-driven 2D drawing API for [[FlightGear]]. | A property-driven 2D drawing API for [[FlightGear]]. | ||
== Status | == Status 07/2013 == | ||
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 this texture on some model in the scene (eg. display, HUD,...). This so called canvas should be controlled only by using the property tree. | ||
Currently it is possible to draw text and arbitrary paths, transform them, change styles and all of this through the property tree. There exists also an experimental Nasal API which provides an object orientated wrapper around the property tree interface to the canvas. | Currently it is possible to draw text and arbitrary paths, transform them, change styles and all of this through the property tree. There exists also an experimental Nasal API which provides an object orientated wrapper around the property tree interface to the canvas. | ||
In 07/2013, Tom added a decoration engine, and improved the C++ window manager to allow creating shadows and window decoration with a single line of Nasal code. | |||
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'. | 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'. | ||