Hi Ryven,
I have to recommend that you update to the latest in SVN as the
threading has been simplified a bit, and there is the rendering is now
factored out into an osgViewer::Renderer classes that replaces
ViewerDoubleBufferedRenderingOperation.
W.r.t extending to add syncronization - as said in my previous email
all it requires is external controls for setting the swap ready
barrier, there is already a barrier in place in startThreading so this
just need altering a little to allow you to provide you own swap ready
sync barrier.
W.r.t multi-screen set up, this is supported via a master Camera
controlling the overall aspect of the view, with slave Cameras
attached to each of GraphicsWindow place on each screen. The slave
Cameras by default are relative to the master Camera and are update on
each frame. You can detach slave Cameras, or just use CompositeView
and have several master cameras. Have a look through all the
examples that reference Camera to learn more about this.
Robert.
On 8/23/07, Ryven <[EMAIL PROTECTED]> wrote:
> Hi Robert,
> m first aproach was to sbclass, the then I realized that I couldn't
> extend the startThreading method, to add the changes needed to the
> cluster. and The operation ViewerDoubleBufferedRenderingOperation was
> declared and implemented on the viewer.cpp , so I could not use it on
> the extended renderingTraversals.
>
> I've tested just now setting the projection, with only one screen it
> works, but with multiple screens / or stereo, it seems to get
> overridden,
>
> viewer.realize();
>
> //setting up perspective
> osgViewer::Viewer::Cameras cameras;
> viewer.getCameras(cameras);
>
> for (osgViewer::Viewer::Cameras::iterator current_camera =
> cameras.begin();
> current_camera != cameras.end();
> ++current_camera)
> {
> (*current_camera)->setStateSet( global_state_set.get() );
> (*current_camera)->setProjectionMatrix(
> multi_frustum.calculateProjection() );
> }
>
> Ryven
>
> On 8/23/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
> > 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
> >
> _______________________________________________
> 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
