One more question--something I've been hung up on the last few hours and I can't get past. See below:
On Fri, 2006-07-28 at 17:39 +0100, Robert Osfield wrote: > 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. I decided to go with this method and I have it working--kind of. :) (Screeny: http://cherustone.com/Screenshot.png) Here's the problem: Cairo represents data internally as ARGB; however, the closest thing OpenGL has to that is RGBA or BGRA, neither of which work. I've tried osg::Image::allocateImage using both GL_RGBA and GL_BGRA, but only GL_RGBA actually causes the Texture to "draw" anything. I've tried every combination of setSourceFormat on the Texture I can think of, to no avail--the colors are swapped are definitely wrong. How can I convert between how Cairo stores the data (ARGB, 0xAARRGGBB) and how OpenGL/OSG wants it (RGBA, 0xRRGGBBAA or BGRA, 0xBBGGRRAA)? Is there something obvious I'm misunderstanding? If not, do I need to swizzle the bits (or whatever it's called) myself? If so, where's the best place to do that? Someone said doing it in a fragment shader would be the fastest... > 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/ > _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
