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
[email protected]
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
[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
