Cool :)
Then thinking back on my problem i think i have an issue about
synchronization (because i have rtt works it looks like it's not the
good frame renderer). It seems that the projection matrix i set (in
ortho) is not yet updated for the current frame i want to grab. In fact
for my two camera rtt, only one seems synchronized with the projection
matrix.
And because it does not work for the cull draw on a different tread, it
could makes sense. I have to dig it, but i have not the time yet, (i
changed the threading model as a work around).
Thank you to answer to this thread it was interesting to read you answers
Cedric
Wojciech Lewandowski wrote:
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
[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
_______________________________________________
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
