Thanks, Art -- I wasn't aware that attaching FBOs to StateSets was
supported. There are no examples that demonstrate this usage.
I like the idea of leaving FBOs as StateAttributes and forcing the app
to set them up explicitly, as opposed to the current FBO handling in
Camera and RenderStage where FBOs are managed under the hood with little
app control.
However, I have two concerns:
1) How would an OSG app render into an FBO with multisampled
renderbuffers, then glBlitFramebuffer into a second FBO to resolve the
multisampling? Would this require a Camera post-draw callback? (This is
currently handled automatically by RenderStage.)
2) Ripping the current FBO management out of Camera and RenderStage
would probably break many applications. Is there a way to move forward
that doesn't break existing apps?
Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ <http://www.skew-matrix.com/>
+1 303 859 9466
Art Tevs wrote:
Hi Robert, Paul
I think having FBOs as a StateAttribute shouldn't be changed. In this way one
can use FBOs also without cameras, which is very appropriate for osgPPU for
example.
However I think we should change how they are handled by the cameras. Currently
there is a problem when mixing FBOs in cameras and FBOs as StateAttributes
inside one scene graph. Here is a simple scene graph which breaks camera's FBO:
root
|
camera (with FBO)
|
scene -- node B -- node C
|
FBO (StateAttribute)
|
node A
If rendering the scene like this, then the node A is get correctly rendered
into the FBO. However, node B and C are then not rendered into the camera's FBO
but just onto the screen.
The problem is, that camera's FBO is not handled like a StateAttribute, which cause osg to restore the state before FBO of node A was applied. When it restores the state, it does not bind the previously bounded FBO back, but it just bind an FBO with id 0. This means that everything rendered afterwards is not rendered into camera's FBO anymore but just on the screen.
So, what I would propose is to change the way, how camera handles FBOs. Maybe
we should always place an FBO as stateattribute just right after the camera
before the camera's subgraph?
So, I agree that there must be done some changes in current situation. However, I would propose to let FBOs as StateAttributes and get them out of the camera, osgUtil::RenderStage and every other place, where they are unapropriate. So put the functionality of osgUtil::RenderStage into the FBO. This would reduce the dependencies between osgUtil and osg and should collect the code on its right place. Even more the FBOs can then still be used just as StateAttributes allowing specifing rendering into an FBO directly without any camera inbetween.
What do you think?
Cheers,
art
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
