Hi Paul, On 15 February 2013 04:09, Paul Martz <[email protected]> wrote: > Now that I give this some more thought, the concept of post-processing is > inherently non-spatial, so it really doesn't belong in a scene graph at all. > Repeatedly "culling" entities that we know will always be rendered is > redundant at best. 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?
Post processing techniques introduce some introducing conceptual and implementation issues, and as you point out conceptually a post process isn't directly part of the scene, rather it's more closely associated with how you view the scene. This conceptually aspect puts it's either up in the viewer and outside of the scene graph, or between the viewer and scene as an intermediate layer. Implementation wise the intermediate layer could be done in the viewer itself, but the viewer tends to have a static list of cameras, and the post processing effects need to be done per viewer camera so placing the cameras directly in the viewer might pose problems in itself if the cameras at viewer or in the intermediate level at at all dynamic. This issue would suggest nested the intermediate layer below a viewer camera. Performance wise viewer cameras can been threaded - both when handling multiple contexts and when handling multiple cameras on a single context. The later might be of interest here ideally you'd want to interleave the cull and draw dispatch of multiple cameras on a single context such that cull0 runs and completes, then cull1 and draw0 run in parallel, then cull2 and draw1 run in parallel etc. For best performance we'd want to take advantage for this in the intermediate level as well. To here we have a motivation for putting the post processing cameras into viewer. Or... have a scheme where the viewer's level Camera's have their Renderer collects the nested Cameras from the intermediate level and then do threading on these. This might achieve the best of both worlds. A twist on this might be to have the CullVisitor spot places where it can thread cull and draw dispatch as it hits Camera's in the scene graph. The later approach would have the advantage of working with existing scene graphs and NodeKits like osgShadow. On the topic of re-using RenderBin's when doing multi-pass, this is partially possible right now, but you really have to know how the rendering back end works and the constraints you have to work within to prevent everything getting out of sync. In most cases it's simply not possible to reuse RenderBin's as even if the same objects make it into the RenderBin their state will mostly be different, and the only way you know what the state is is by collecting the state in the cull traversal so you still have to do the cull traversal and build a unique StateGraph and with it unique RenderLeaf and which also require a unique RenderBin. The times when sharing RenderBin is possible really is very limited and has to be assessed on a case by case basis. If we do want to explore the possibility of greater re-use of cull results then I think we best look at extending CullVisitor and the rendering back end in a way that enables new ways of managing things. One could perhaps provide a convenience methods that provided similar set up functionality to an osg::Camera and make it easier to use this type of functionality, this would make it lighter weight to avoid using osg::Camera, but this is added complexity that we would have to look very carefully at as being properly justified. It might be that a better solution might be to enable easier management of osg::Camera that are used to implement these techniques, so that the user front end doesn't need to worry about the how the scene graph is implementing a post processing effect, it just configures the interface it needs and the back end goes away and does what it needs. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
