[osg-users] Performing non-rendering actions between renderbins

[Jason Baurick]

Hi Robert,

My in-experience with OSG made using the CompositeViewer easy, the explicit
methods to add additional views jumped out as a quick and easy way to
accomplish the goal of multiple views of the scene, each with a slightly
different data set.  In hind-sight I realize that it may not be how I would
accomplish the task if I was to start over.

As for putting together a basic osgcompositor app, I would love to but I
don't own the copyrights for all the code I am writting, this has been both
a work project and a personal project.  Based on your interest in the
concepts up to this point I have started the process of getting permission
to open up my code, I don't expect it will be an issue, but I don't have a
timeline on it.

- Jason

On Sat, May 10, 2008 at 12:30 AM, Robert Osfield <robert.osfield at gmail.com>
wrote:

> Hi Jason,
>
> On Fri, May 9, 2008 at 10:27 PM, Jason Baurick <baurick at gmail.com> 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 at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
--Jason Baurick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080512/760d81bd/attachment-0001.htm>