Hi Jeremy, The easiest way to do it would be to implemenat as custom osg::ImageStream. ImageStream is a subclass from osg::Image, with added controls for imagery that is updated dynamically, typically used for video. For an example of a custom ImageStream see the xine-lib plugin.
Once you have you custom ImageStream working you'll be able to utilize PBO to effeciently update the texture and this will all be done automatically for you, you just have to concentrate of populating the image data associated with the ImageStream. Depedening on your app usage though, you may not even need to subclass from osg::ImageStream, just creating a osg::Image would probably be enough. Every time you update its data you just need to call dirty() on the image and it'll be automatically download. The osg::Image itself could be a non power of two, but if you assign it to a Texture2D without using NPOT texture support (only available on OpenGL 2.0 with latest hardware), there will be a rescaling done on every update. As you've already spotted the alternative is to use osg::TextureRectangle, and this should work just fine too, avoiding the resize but with better support for older hardware. Have a look at the osgmovie example, and the xine-lib plugin, in particular the code setting up the osg::ImageStream. It does create its own thread, which you may be able to avoid, since I presume Cairo will be fast enough to do the image update well within a ms or so. Robert. On 7/28/06, Jeremy L. Moles <[EMAIL PROTECTED]> 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/
