Well, I've got the basics of it working, demonstrated in some screenshots here:
http://cherustone.com/osgCairo The general gist is: // ------------------------------------- osgCairo::SurfaceImage* image = new osgCairo::SurfaceImage(256, 256); osg::Texture2D tex = new osg::Texture2D(); tex->setImage(image); image->drawCairoFoo(); image->drawCairoBar(); image->drawCairoBaz(); image->dirty() / -------------------------------------- Basically, this lets you use images as a kind of "canvas" with OSG easily. This also means that with a few tweaks (that I'll have finished this week), OSG will be able to load SVGs, PDFs, and PostScript files as textures--not that anyone would want to use PDFs or PS files. :) Furthermore, I'll eventually make a high-level "windowing" wrapper around this that lets users create vector-based windows, widgets, and other UI-esque things. I already have a prototype for this called "Egypt", but it's in Python and is very, very slow. :) (Think "Flash-like" interfaces in games) With enough polish, could something like this (osgCairo) go into OSG--or at least be listed on the website? I've followed the coding conventions as close as possible, though it was very easy seeing as how I already use OSG-style C++ in the first place. :) On Fri, 2006-07-28 at 12:06 -0400, Jeremy L. Moles wrote: > I'm looking at integrating the Cairo (http://cairographics.org) vector > graphics library into OSG via osg::Texture*. This will allow me to use > the nice Cairo API (which I am very familiar with) to draw sharp, clean, > vector-based HUDS on Textures using OSG. Before I get started though, I > had a few questions regarding OSG and how it handles Textures. > > First of all, is going the "texture" route even the most optimal? Cairo > supports many backends, but it's most basic backend is simply an image > buffer with explicit format semantics. My idea was to inherit from > osg::TextureRectangle and implement the Cario API in the subclass, which > in turn will operate on the Texture's internal osg::Image object. This > is all fine and dandy, except I'm not quite sure what to do when a user > wants to change the internal image buffer and have that update the > texture in VRAM. Recreating the texture, obviously, is out of the > question. > > I guess my question then is: what is the basic strategy for using a > Texture in OSG as a kind of "interactive" canvas? > > glMapBuffer/glUnmapBuffer seems like it would be nice in this case, > though I've only ever seen VBO's used for vertex data. Is this a case > where I need FBO's instead? I don't really know anything about them, but > Googling leads me to believe they could be helpful here. The osg > FrameBufferObject also looks promising, but I'd want someone else to > push me in that direction before I wasted time on something unfruitful. > > Sorry if this is a dumb question... :/ > > _______________________________________________ > osg-users mailing list > [email protected] > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ > _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
