Hi Mika,
Is it possible that you provide me with a simple test case implementation to
test it. Because then maybe I would be able to find an answer how to correct it.
>
> However, this causes another problem which I don't even begin to understand
> (which may or may not be related to osgPPU). Everything would be perfect,
> except for some reason now there's an extra call for
> glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0) before the main osgViewer camera
> renders (apparently after already having earlier bound the correct FBO). This
> makes it draw directly to the screen, which is wrong. It does have its FBO
> attachments and textures and they're even cleared correctly before rendering,
> but for some unexplained reason it makes this binding that ruins everything.
> I've spent hours stepping around in OSG's sources and while I can see where
> this call is made, I have no idea why. It's in FrameBufferObject.cpp,
> apply(State, BindTarget), this part:
>
> if (_attachments.empty())
> {
> ext->glBindFramebufferEXT(target, 0);
> return;
> }
>
> (called via osg::State::applyGlobalDefaultAttribute(), the buffer attachment
> list for osgViewer's camera isn't empty - is it applying some default state
> settings when they're not wanted?)
>
I think osgViewer's camera is binded to FBO 0, because this is a main camera
which suppose to render to the screen. You could try to add a second camera
below the osgviewer's, which renders your scene into FBO. Then use the output
of this camera for further processing. So the graph could look like this:
osgViewer
|
+--- depthCamera (with PRE_RENDER, to an FBO) ------- (stuff)
|
+--- colorCamera (with PRE_RENDER, to an FBO) --- (stuff)
|
+--- PPU-Graph
|
+--- (same stuff)
This will cause your rendering to be performed into FBOs and processed by
osgPPU. The ppu graph will have just no output to the screen, so no UnitOut at
the end. It will just process your renderings and the output textures should be
then used in the rendering of the main scene.
The ppu graph will look similar to this:
Processor
| |
UnitCamera UnitCamera
\ /
UnitInOut
I am not exactly sure, but here it still can happen that osgPPU will be
executed after your main scene is rendered, so that you get this one frame
delay.
>
> Also another approach of adding a group with renderbin -1 to the main level
> and parenting the processor to this gives pretty much the same results and
> problems.
>
If you want to change the render bin number of processor, you do not have to
put it under a group and change the group's bin number. you can try to do it
directly by getting processor's stateset and change the rende rbin number there
(processor is derived from Group).
cheers,
art
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=15947#15947
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
