Canvas properties: Difference between revisions

Jump to navigation Jump to search

Canvas properties (view source)

Revision as of 13:31, 9 May 2013

1,872 bytes removed ,  9 May 2013
→‎Images: Static Textures & Cascaded Canvases {{Done}}: remove brainstorming (implemented)
(→‎Images: Static Textures & Cascaded Canvases {{Done}}: remove brainstorming (implemented))
Line 70: Line 70:
=== Depth Sorting {{Done}} ===
=== Depth Sorting {{Done}} ===
Normally elements inside a group are drawn in the order they appear in the property tree. By adding a "z-index" property to certain elements it is possible to change the render order inside a group. It's value defaults to zero, therefore setting a negative value renders the according elements below its siblings and a positive index above the other elements.
Normally elements inside a group are drawn in the order they appear in the property tree. By adding a "z-index" property to certain elements it is possible to change the render order inside a group. It's value defaults to zero, therefore setting a negative value renders the according elements below its siblings and a positive index above the other elements.
=== Images: Static Textures & Cascaded Canvases {{Done}} ===
Status: http://gitorious.org/fg/flightgear/commit/310ddbf8c5bfd6807eac79fb9cf22f6801bb80ad
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).
With knowing the texture id it should be trivial to get a binary dump. Either by using some OSG methods or just with glGetTexImage.
Yes, basically like the unix philosophy: "Everything is a file", right?
That's a powerful concept, because it means interoperability and it would support recursion in the case of the canvas system.
The "canvas://" syntax looks good to me, for files one could use standard "file://" then.
On the other hand, these two things could also be implemented as extensions of the property tree.
Basically, two new property "sub types": string:filename and string:canvas
I read about this idea somewhere on the wiki, so it was discussed previously.
That would be a simple change, and it would help "typing" properties a little more, the extension would also be useful for other systems which deal with file names or paths, because it would be much easier to handle validation of file names and directories at the core level


=== Nested/shared "multipass" Canvases ===
=== Nested/shared "multipass" Canvases ===
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/59999"

Navigation menu