20,741
edits
Canvas properties: Difference between revisions
Jump to navigation
Jump to search
m
→Planned Features
No edit summary |
|||
| Line 48: | Line 48: | ||
* Support implementing GUI widgets using Canvas/Nasa (currently being discussed) | * Support implementing GUI widgets using Canvas/Nasa (currently being discussed) | ||
* Static image files should be handled like any other element on the canvas. Only instead of specifying a path you'll have to set the file system path to an image which will be loaded with osg. | * Static image files should be handled like any other element on the canvas. Only instead of specifying a path you'll have to set the file system path to an image which will be loaded with osg. | ||
=== Static Textures === | |||
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 | |||
=== Vector Images === | === Vector Images === | ||