Hi,
In my present implementation in the osgRecipes project, I create a list of
pre-render cameras internally as post processing passes, instead
of explicitly in the scene graph. So on the user level they may simply
write:
EffectCompositor* effect = new EffectCompositor;
effect->loadFromEffectFile( "ssao.xml" );
effect->addChild( subgraph );
And during the cull traversal, cameras (and screen quads) are added
directly to the cull visitor:
cv->push*();
camera->accept(*cv);
...
cv->pop*();
This simplifies the class interface but doesn't change the render
stage/render bins we current use. But at least, the post processing passes
are not traversable by a scene node visitor, thus not part of the scene
graph and will not affect intersection test and other updating work, as
Paul and Aurelien point out..
But we may not be able to directly migrate these to a draw callback,
because CullVisitor doesn't really render anything, but will create the
render-graph for SceneView. A possible idea in my mind is to execute the
FrameBufferObject::apply() method along with Quad::drawImplementation()
manually in the draw callback, which means to have another complete
deferred draw process, besides the main renderstage/renderbin back-end. I
don't know if it could be a good choice because the implementation may
finally look like an OpenGL-style one, not an OSG composition.
Thanks,
Wang Rui
2013/2/15 Aurelien Albert <[email protected]>
> Hi,
>
>
> > the concept of post-processing is inherently non-spatial, so it really
> doesn't belong in a scene graph at all
>
>
> => this is why I think we should be able to execute a render pass on an
> arbitrary camera : the subgraph of this camera may not have a spatial
> organization, but a process-logic organization
>
>
> > Wouldn't it be better to have a list of dedicated RTT objects as
> described by Rui, and process them as a Camera post-draw callback
>
>
> => this also my idea : have a dedicated "executeCamera" method which take
> a camera and a state as arguments : with that we can call it from a final /
> post draw call back.
>
> Rather than a list of dedicated RTT objects which will never cover all the
> diferent use cases, I think this is better to re-use the camera class with
> it's subgraph, which already works well : by building different small
> sub-graph we can implement different processing (with a render quad as
> input, or with a point cloud, or with anything else).
>
>
>
> Aurelien
>
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=52688#52688
>
>
>
>
>
> _______________________________________________
> 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
