Hi Jason, On Fri, May 9, 2008 at 10:27 PM, Jason Baurick <[EMAIL PROTECTED]> wrote: > Hi Robert, > > I'll look at osgViewer::Viewer, the reason I used osgViewer::CompositeViewer > is because the methods it provided made implementing something very easy.
I'm curious, what methods made it easier with CompositeViewer? Just the availability of extra master Camera's? If so then slave camera's within a single View(er) should be sufficient. > Right now I am targeting multiple GPU machines, I have looked at clusters in > the past for this problem but that is not the direction I am working in > right now. My inspiration for this project comes from my experience working > in a startup that did transparent OpenGL sort-first and sort-last > compositing, so I have lots of experience with the various compositing > methods already. Scene graphs are certainly a good way to tackle complex rendering set ups efficiently, if the scene graph is flexible enough. I would like see compositing support integrated into osgViewer at some point in the not too distant future. A first step towards this would be to have an osgcompositor example that renders on multiple GPUs and composites the result. This example could be a bit of hack, doing stuff that might be a be dirty to make sure the viewer can be tricked into doing the right thing. The next step after this would be to refactor osgUtil/osgViewer to make support of compositing more streamlined. In terms of helping you out, it'd be much easier to discuss things if we had a code base that we could both review and test first hand, doing email support for complex stuff is really slow and costly time wise. So... any chance you could put together a basic osgcompositor app based on your current experiments? Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
