Hi Ryven,
Copying osgViewer to be able to add the swap read sychrnonization
isn't good. Subclassing would be better. Don't forget copying of the
source code means that your code also has to be release under as open
source the OSGPL, subclassing doesn't have this restriction.
The right way to solve the swap ready is for
osgViewer::Viewer/CompositeViewer to provide external controls for the
swap buffers. There is already a Barrier operation added when
multiple contexts are used, but this isn't created internally in the
osgViewer::Viewer::startThreading() method. In your case you just
need to provide your own Barrier implementation, and have
startThreading() use this. Off hand I can't say exactly what the API
should be, but this isn't that complicated to add so
I'd suggest you look into what changes might be need to facilitate
this and submit these rather go the route of copying code.
Robert.
On 8/23/07, Ryven <[EMAIL PROTECTED]> wrote:
> Thank you all,
>
> We are trying to build a cave environment based on OSG and MPI for
> cluster synch,
> (we have tryed vuggler... but on windows it failed .. a lot..), so we
> have successfully implemented a proof of concept using the sceneviewer
> of the old osg and MPI.
>
> Now we are adding stereo, and I think it is done! (with a lot of work,
> and after reading a lot of osg code), the new osgViewer is ver good
> for multi GPU, we have 2 nvidia 8800GTX to control 2 projectors and
> the osg horizontal split stereo worked pretty good, so we only needed
> to add the cluster swap lock, so... I copied the osgViewer so I cold
> add a glFinish operation to the GraphicsThread, and added the MPI
> barrier after it to synch the cluster. we will need to test it a lot,
> but I think it works.
>
> I asked about the perspective because we need to set a different
> perspective for each node of the cluster. mean while i' understood I
> have to set perspective to the left and right cameras after realize.
> (right?)
>
> for the view matriz I have a dummy manipulator that I update using
> setByMatrix using the matrix send by the master node.
>
> thanks
>
> On 8/22/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
> > On 8/22/07, Paul Martz <[EMAIL PROTECTED]> wrote:
> > > > The fourth way is to attach a custom update callback to the camera.
> > >
> > > Good point. Because events are processed before the update traversal, this
> > > allows the app to override any camera manipulators.
> >
> > My favoured curstom way is still just to set it in the main loop and
> > not register a camera manipulator i.e.
> >
> > Viewer viewer;
> > viewer.setSceneData(readNodeFile("cow.osg"));
> > viewer.realize();
> > while(!viewer.done())
> > {
> > viewer.getCamera()->setViewMarix(myViewMatrix);
> > viewer.frame();
> > }
> > _______________________________________________
> > osg-users mailing list
> > [email protected]
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
