20,741
edits
Canvas properties: Difference between revisions
Jump to navigation
Jump to search
→Static Textures
| Line 50: | Line 50: | ||
=== Static Textures === | === Static Textures === | ||
We talked about supporting static textures via file names and handling them via OSG, it just occurred to me that it would be pretty powerful to support two more features | |||
providing a hook to get a binary dump of the a canvas texture (i.e. as a PNG file) | |||
providing a hook to use another canvas as the input for an image file name in another canvas group | |||
Basically, this would make it possible to recursively use a canvas as the input for another canvas. | |||
And by adding a hook to access the texture of the canvas as a binary dump, Nasal scripts could not only write a canvas texture to the file system, but they could even mime-encode it and send it to the browser (via the built-in HTTP server), so that canvas textures could be shown inside the browser for example, basically canvas textures could be used outside the fgfs process by providing a handle to access the dump. | |||
These two features alone would make it possible for people to draw to a canvas, save it to the file system and even chaining canvases by using the output of one canvas, as the input for another one (a while ago, we talked about the lack of support for chaining od_gauge systems). | |||
And serializing a canvas is trivial because it's just a property tree, so it can be done via save_properties() | |||
Another use case would be this: | |||
1) render a 2D instrument as a canvas | |||
2) provide a GUI dialog to show the same instrument | |||
3) provide features for scaling/transforming the displayed instrument | |||
i.e. these would be building blocks for a GUI aircraft panel editor, with full support for previewing and manipulating instruments. | |||
Everything is just a texture object (canvas, images, etc.) so as soon as images are supported in the canvas everything you described should be possible. I just need to have a look how to best unify the texture handling and mapping from names/ids to texture ids. Maybe we shouldn't even distinguish between canvas texture and image textures and instead use just special filenames/protocols (eg. canvas://name or name.canvas or /canvas/name). | Everything is just a texture object (canvas, images, etc.) so as soon as images are supported in the canvas everything you described should be possible. I just need to have a look how to best unify the texture handling and mapping from names/ids to texture ids. Maybe we shouldn't even distinguish between canvas texture and image textures and instead use just special filenames/protocols (eg. canvas://name or name.canvas or /canvas/name). | ||
With knowing the texture id it should be trivial to get a binary dump. Either by using some OSG methods or just with glGetTexImage. | With knowing the texture id it should be trivial to get a binary dump. Either by using some OSG methods or just with glGetTexImage. | ||