Hi Wojtek, On Thu, Jun 26, 2008 at 5:22 PM, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote: > I am not sure if you read the piece where I mentioned that > Image::allocateImage resets Image::internalTextureFormat to image pixel > format. Image::allocateImage is called from Image::readPixels. So calling > readPixels also changes internal format. This was the main culprit that > second FBO for even SceneView was created with byte renderbuffer despite the > fact that first FBO was initalized to RGBA32F. That happened because, when > an image is attached to RTT camera, FBO Renderbuffer format is selected > after this image internalTextureFormat. In our example internalTextureFormat > was initially set to RGBA32F so first FBO Renderbuffer was initialized to > float but readPixels caused reset to RGBA. So in next frame, when second FBO > was created it initilized with standard 32 bit ubyte format.
I did spot this, but didn't really have anything to add. Clearly it's a bug, but without putting time into fully understanding the failure mechanism I can't give any guidance. With all the build problems kicking off this week I'm a bit too stretched thinly to go chase this up. > I am not sure if this is a bug, but in my opinion Image::allocateImage > should not change internalTextureFormat or at least Image::readPixels should > record and restore internalFromat after calling allocateImage. I don't follow, are we talking about the the format in osg::Image or the texture? Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
