Hi all, Thanks for the replies. It is always midnight for me when most community members are active so I have to reply to you all later in my morning. :-)
Paul, I haven't done any comparisons yet. Post processing steps won't be too many in a common application, and as Robert says, the cull time cost of a camera and a normal node won't be too different, so I think the results may be difficult to measure. Aurelien's past idea (using RenderBins directly) also interests me but it will change the back-end dramatically. I'm also focusing on implementing a complete deferred pipeline including HDR, SSAO, color grading and AA work, and finally merge it with normal scenes like the HUD GUI. The automatic switch between DS and normal pipeline is done by changing whole 'technique' instead of moving child nodes, which may be found in the osgRecipes project I'm maintaining. But I don't think it easy to implement an executeCameraAsync() method at present. As OSG is a lazy rendering system and one can hardly insert some CPU side computation into FBO cameras. Maybe it could be done by using pre- and post-draw callbacks of a specified camera. I also agree with Daniel's second opinion that the pipeline should be compatible with multi-views. As a node in the scene graph we can easily do this by sharing the same root node in different views. For the first opinion, because we also have nodes that should not be affected by the post-processing effects (like the GUI, HUD display), and developers may require multiple post effects in the same scene graph (e.g., draw dynamic and static objects differently), I don't think it convincing to totally separate the post processing framework and place it in draw callbacks or viewer's graphics operations. So, in conclusion, I will agree with Robert that OSG itself don't need an additional RTT node at present and will use cameras to perform every passes, which is already proved in my client work to be compatible with most current OSG functionalities including the VDSM shadows, and some external libraries like SilverLining and osgEarth. I will try to tidy and submit my current code in the next week as well as a demo scene. And then I will modify the osgRecipes project to use the new idea flashed in my mind to find the pros and cons of it. Thanks, Wang Rui
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
