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.
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. Just having access to the scene graph solves many of the problems that we where unable to efficently solve as a transparent OpenGL layer. Things like data decompositing become trival in a scene graph and are next to impossible to do efficently when all you are getting is the raw polygon data. Thanks for your help and interest. - Jason On Fri, May 9, 2008 at 1:36 AM, Robert Osfield <[EMAIL PROTECTED]> wrote: > Hi Jason, > > For your compositing like you are doing I'd suggest using > osgViewer::Viewer rather than osgViewer::CompositeViewer, as when > doing compositing you are logically managing a single view of the > scene, even though its composed of a number of slave cameras. A > CompositeViewer is for composing a viewer from multiple views, > although given the name Composite in the class name I can certainly > see the draw, just in this case its composing views, rather than > blocks of rendering. It may be that eventually you'll want to use a > CompositeViewer managing multiple views, that each are doing their own > compositing too... ;-) > > BTW, what hardware set up are you targeting? A cluster, a multiple GPU > machine? Is there a particular paper you are using for inspiration > for you work? > > Robert. > > On Thu, May 8, 2008 at 9:04 PM, Jason Baurick <[EMAIL PROTECTED]> wrote: > > Hi Robert, > > > > Ideally I would do this at a higher level, I am just new to OSG in > general, > > so I took the first path I found that would do what I needed. Setup is > > actually done above the CompositeViewer in my prototype and I would like > to > > do the entire process at that level. I was looking at making a > > CompositedViewer class that handled all the details I do outside the > > existing viewer structure. > > > > Thanks for the pointer on renderstages/renderbins. I will begin looking > at > > that latter today and see what I can do with them. > > > > - Jason > > > > On Wed, May 7, 2008 at 8:57 AM, Robert Osfield <[EMAIL PROTECTED] > > > > wrote: > >> > >> Hi Jason, > >> > >> Compositing is topic that I haven't personally tackled yet, but am > >> very curious about it, and something I something that osgViewer could > >> probably evolve to help out with it. I say evolve as it doesn't have > >> an explicit support for it right now, but in terms of functionality > >> compositing is a high level feature that depends upon the hardware > >> setup rather than the scene itself, so is natural to implement it at > >> the higher level of the viewer, rather than embedded in the scene > >> graph. It would be nice to have composite support as a configurable > >> feature of osgViewer just like management of multiple graphics > >> context/displays. > >> > >> To implement what you need right now it might well be best to > >> modify/subclass osgUtil::RenderStage/RenderBin to provide the hooks > >> you require as its the object in the rendering backend that does the > >> rendering. I'm open to see required changes merged into the core > >> OSG, with a view to see compositing support make its way into a core > >> feature of osgViewer. > >> > >> Robert. > >> > >> On Wed, May 7, 2008 at 3:48 PM, Jason Baurick <[EMAIL PROTECTED]> > wrote: > >> > Hi Robert, > >> > > >> > I'm implementing various sort-last compositing methods using OSG. For > >> > depth > >> > compositing you need to composite after the opaque data has been > >> > rendered > >> > but before the transparent data has been rendered. Compositing is > >> > actually > >> > done with buffer transfers Read Pixels, Texture Images, PBOs, etc... > >> > > >> > Since each view has to do different work I just added Geodes with > custom > >> > drawables to the scene graph which do the required GL action. The > >> > problem > >> > with this method is I'm adding at least one node for each GPU I want > to > >> > work > >> > with, in some sort-last cases multiple nodes per GPU. This is not a > >> > clean > >> > implementation in my opinion. So I am looking for other ideas on how > I > >> > can > >> > insert operations in-between rendering bins. > >> > > >> > - Jason > >> > > >> > > >> > On Wed, May 7, 2008 at 2:59 AM, Robert Osfield > >> > <[EMAIL PROTECTED]> > >> > wrote: > >> > > Hi Jason, > >> > > > >> > > What do types of operations are you looking to do? > >> > > > >> > > Robert. > >> > > > >> > > > >> > > > >> > > > >> > > On Mon, Apr 28, 2008 at 9:58 PM, Jason Baurick <[EMAIL PROTECTED]> > >> > > wrote: > >> > > > Hi, > >> > > > > >> > > > I recently started working with OSG and I have what is hopefully a > >> > simple > >> > > > question. I have a composite viewer with two views, I want to > >> > > > perform > >> > an > >> > > > action on the buffers in each view between the opaque rendering > and > >> > > > the > >> > > > transparent rendering, each view needs to perform a different > >> > > > action. > >> > > > Currently to make this work I added two nodes to my scene graph, > >> > > > culled > >> > out > >> > > > one for each view and then stuck them in a renderbin between the > >> > > > opaque > >> > and > >> > > > transparent bins. So I guess what I'm asking is if there is a > >> > > > simpler > >> > way > >> > > > to do this? I tried setting up camera callbacks, but this happens > >> > > > at > >> > the > >> > > > wrong point, my next thought would be to overload the draw > >> > > > traversal. > >> > > > > >> > > > Any suggestions would be welcomed, thank you in advance. > >> > > > > >> > > > -- > >> > > > --Jason Baurick > >> > > > > >> > > > _______________________________________________ > >> > > > osg-users mailing list > >> > > > osg-users@lists.openscenegraph.org > >> > > > > >> > > >> > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> > > > > >> > > > > >> > > _______________________________________________ > >> > > osg-users mailing list > >> > > osg-users@lists.openscenegraph.org > >> > > > >> > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> > > > >> > > >> > > >> > > >> > -- > >> > --Jason Baurick > >> > > >> > _______________________________________________ > >> > osg-users mailing list > >> > osg-users@lists.openscenegraph.org > >> > > >> > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> > > >> > > >> _______________________________________________ > >> osg-users mailing list > >> osg-users@lists.openscenegraph.org > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > > > -- > > --Jason Baurick > > > > _______________________________________________ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- --Jason Baurick
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
