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
[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
--
+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
