Hi Robert, After I sent the message, I realized I had inadvertently omitted the 'A' in RGBA. Once I put that in, I started seeing the image. Once I got that working I realized I wasn't twiddling the bits correctly. The G_UNSIGNED_BYTE was the easy fix. I probably would have never realized it was an option if you hadn't suggested it.
I spent a lot of time looking at the implementation of osg:Image trying to figure out how to get this working. One thing that never became clear is what actually uses the data stored in the osg::Image instance. I looked at some of the code in the osgProducer namespace. It calls to mind well-known literature of the 19th century logician, Charles Lutwidge Dodgson. "Curiouser and curiouser!". It's like trying to assign responsibility in Washington. Are there any scene-graph diagrams depicting the runtime structure of a simple representative OSG-based program? What about a description of the execution cycle which explains the order of evaluation for update and rendering operations? On Tuesday 31 October 2006 13:20, Robert Osfield wrote: > Hi Steven, > > Try just using a standard data type rather than > GL_UNSIGNED_SHORT_4_4_4_4, i.e. GL_UNSIGNED_BYTE, and you'll need to > make sure the pixelformat is RGBA if you are going to set 4 values. > > Robert. > _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
