Hi again Cedric,
I think I have last piece of the puzzle. It looks like readPixels work
perfectly correct with float Renderbuffer. I was blaming it because scene
background was properly darkened by postRender camera callback but rendered
cessna model seemed unafected by image darkennig process. Image darkenning
was done by simple color scaling by 0.5.
It turned out that cessna interior was also properly scaled. But when
Renderbuffer was float, render buffer color compononts were not clamped to
0..1 range (which is obvious for float buffers, but I always forget about
it;-). Shaders were substituting colors with vertices and multiplying them
by 2 (Sine uniform) so even after scaling by 0.5 we were still having color
components much larger than 1.0. Thats why cessna interior seemed not
darkened at all.
Jeez, I learned a lot today ;-) Thanks for interesting example ;-)
Cheers,
Wojtek
Hi Cedric,
I just have found one more bit of info. Image internalTextureFormat gets
reset by Image::allocateImage called from Image::readPixels when RTT
camera buffer contents are read into image after first draw. So this does
not happen when texture is applied for final scene draw.
I am not sure if resseting internal format from GL_RGBA32F_ARB to GL_RGBA
should not be considered as a bug ?
However, it still does not explain what happens with image during and
after readPixels got called when render buffer was GL_RGBA32F_ARB.
Cheers,
Wojtek
Well thank you for helping,
You give me a lot of imformation, i will dig it
Cedric
Wojciech Lewandowski wrote:
Hi Cedric,
If someone has some clue or advise to dig it
Sorry I had no time to look at the repro you created. I looked at your
earlier modified
prerender example though. I got curious and started to debug it I think
I found some additional important circumstances and workaround that my
help you. But topic is quite mixed nad complex and I may have problems
explaining it. But here it goes:
Both DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext
modes
use osgViewer::Renderer thread with double buffered SceneViews.
SingleThreaded and CullDrawThreadPerContext use single SceneView for
rendering. (CullDrawThreadPerContext also uses Renderer but only with
one
SceneView see osgViewer::Rendered::cull_draw method in comparison to
osgViewer::Renderer::draw & osgViewer::Renderer::cull)
Double buffered SceneViews mean that there are two interleaved
SceneViews
performing cull and draw operations for subsequent odd/even frames.
These
two scene views share some resources but may also create some separate
resources. For example, if texture is attached to RTT camera, each of
these SceneViews will create two separate FBOs for
this camera but these FBOs will share camera texture. But when you
attach the image to RTT camera, each of these FBOs will create
spearate render buffer and will read pixels to the camera image from the
buffer.
What seems to be the case in your modified osgprerender looks like there
is
either some problems with refreshing the image in one of these
SceneViews. I ran your example through gliIntercept and found something
really weird. First SceneView FBO creates Renderbuffer with RGBA_32F
format but second SceneView creates RenderBuffer with RGBA format. So
you end up with situation when odd RTT camera frames are rendered into
float framebuffer but even frames are rendered into ubyte framebuffer.
Apparently readPixels from float buffer fails somehow and only read
pixels from ubyte work as intended.
I got curious why first SceneView FBO uses float buffer but second uses
ubyte buffer. I think the answer is following: Apparently first frame
drawn by prerender RTT camera proceeds before rendered texture is
initialized and aplied to draw final scene. When first FBO is created
its render buffer is based on initial image internal format (RGBA_32F).
FBO is build and used to render first frame and then its contents are
read to the image. Then main camera draws scene using texture initilized
from updated image. When this texture gets applied for the first time,
image internal image format gets changed to texture format (RGBA) and
thus second FBO is created using this different format
So we end up with odd prerender frames rendered into RGBA_32F buffer and
even frames rendered into RGBA byte buffer. But this does not explain
why readPixels produce so visually different results. It looks like
there might be additional bug in OSG or OpenGL in reading pixels from
RGBA_32F framebuffer.
Now time for the conclusion. I don't have much time to dig this further,
and see why readPixels fail, maybe will investigate this some other day.
So I don't have a real fix, but you may try a simple workaround. Set
initial internal image format to RGBA instead of RGBA_32F. I did that
and it seemed to remove the discrepancy. Alternatively make sure that
texture build from image has its internal format set to RGBA_32F. But I
did not try this option.
Cheers,
Wojtek
J.P. Delport wrote:
Hi,
for our current app we use singlethreaded. FBO is a requirement
because of multiple render targets.
Best would be to fix multithreaded and FBO. For this we will need
small test apps that reliably trigger errors.
Problem is that I think most people are unsure whether they are
abusing OSG (not using the library correctly, not setting dynamic
correctly, not blocking correctly...) or whether it is a bug.
jp
Cedric Pinson wrote:
What do you use to have a robust solution ? maybe i should just use
something different than fbo ?
Cedric
J.P. Delport wrote:
Hi,
Cedric Pinson wrote:
Hi,
I would like to know if other found some strange issue with multi
threaded, and render slave camera to fbo.
Yes, there have been quite a few discussions about multithreaded and
fbo in the recent months, but AFAIK nobody has put a finger on the
exact problem yet.
Attached is a simple modded version of osgprerender that also
displays something strange in multithreaded. I'm not sure if it is
related though.
run with:
./osgprerender --image
The image flashes every second frame for some reason. (Turn sync to
vblank on so it does not flash too fast.)
If, at the bottom of the .cpp, one enables the single threaded
option, the flashing disappears.
I have tried setting properties to dynamic on scene nodes, but it
does not seem to help, or I am missing a critical one.
jp
------------------------------------------------------------------------
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
+33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED]
http://www.plopbyte.net
--------------------------------------------------------------------------------
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
+33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED]
http://www.plopbyte.net
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
