Hi Robert,
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 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.
Cheers,
Wojtek.
Hi Guys,
I've just skimmed through this thread. Interesting issues :-)
Wojtek explanations of the double buffered SceneView is spot on, in
this case leading to two FBO's, Creation of two FBO's for RTT is
something I've been aware of since the inception of the
DrawThreadPerContext/CullThreadPerCameraDrawThreadPerContext, but as
yet haven't had the opportunity to refactor the code to avoid it.
The problem actually stems from the reuse of SceneView to do something
that it was never intended to handle, and in terms of osgViewer
implementation SceneView was used simply because it was the line of
least resistance i.e. it worked and code be adapted to help speed up
the implementation of osgViewer, and mostly it's actually worked out
ok, the stop gap has worked out pretty well.
However, it has always been my plan to rewrite the osgViewer::Renderer
so that it doesn't use SceneView at all, let alone double buffering
them, instead it's my plan to use a single CullVisitor which
alternately populates double buffered RenderStage. This approach
would be far leaner and less obfusticated, and we should be able to
clean up some of the artefacts as well. The downside is by not using
SceneView we'll loose all the stereo rendering support, so instead
we'll need to refactor osgViewer so that stereo rendering is done at
the viewer level i.e. using slave cameras - this means more coding
work, but the actually end result would be far better both design wise
as well as in flexibility and performance.
I just need to time to go off and do this work, I might be able to get
it done for 2.6, but spare time certainly isn't something that I'm
blessed with right now.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
