20,741
edits
Canvas properties: Difference between revisions
Jump to navigation
Jump to search
m
→Status 07/2013: update
m (Update forum links) |
m (→Status 07/2013: update) |
||
| Line 10: | Line 10: | ||
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 | Currently it is possible to draw text, arbitrary OpenVG paths, use vector and raster images and transparently create geographic maps, transform them, change styles and all of this through the property tree. There's also a 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. | 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. Meanwhile, Canvas textures can be used in cockpits/aircraft, GUI windows and dialogs and as part of the scenery. | ||
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'. | ||