Its really hard to know whats going on at your end w.r.t application
setup and flow control so advicing on it is easy. In general I can
say that sharing a scene between View's is OK within on
CompositeViewer as they will Views on the same scene will share the
same FrameStamp i.e. there will be all at the same point in time.
Sharing one scene between multiple Viewers will hit up against the
problem that in one set of traversals the scene graph is one time and
then the traversals from the other viewer will try to change the time
back - and likely to cause a mess. This timing issue isn't likely to
cause problems with high level rendering though - it should just mess
up things like particle systems and sequences.
Robert.
> _______________________________________________
> osg-users mailing list
> osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
On Fri, Feb 22, 2008 at 7:11 PM, nicolas peña <mr.an...@gmail.com> wrote:
> I have done several tests and have reached to the conclusion that it is not
> possible to use two viewers at the same time from one process.
Are you running the viewers single threaded? If so then the lazy
setting of makeCurrent for each for the viewers will mean that after
the first frame the makeCurrent won't be called as the viewer assumes
that it already has the context current so can save the cost of the
makeCurrent. Interleaving two viewers in the same thread would then
cause one viewer's GraphicsWindow to be the one that is current and
the other will never be updated. osgViewer hasn't been designed for
this usage model - one that I haven't ever thought of as a combination
in fact - its support may different combinations of viewer usage but
just not this one I'm afraid.
Potentially we could modify osgViewer::ViewerBase to allow you to use
the viewer in this way i.e. have two viewers called from the same
frame loop thread, this would require switching off the lazy
makeCurrent mechanism - the method that does it is
ViewerBase::makeCurrent(osg::GraphicsContext* gc) that you'll find in
include/osgViewer/ViewerBase. Perhaps a bool flag in ViewerBase could
be used to enable the lazy makeCurrent() for instance.
> This happens even when they do not share anything and even if I set-up
> the viewers from different threads.
> I have done the most simplistic code and even this fail.
> I'm using OSG 2.3.4 on Linux 2.6.22 with NVIDIA proprietary drivers.
>
> I would like to help to solve this if you confirm it as a bug and if it is
> possible.
You usage model is rather unusually so you using osgViewer out of
scope, so rather than bugs its most design limitations. The OSG is
not a static object - it evolves over time in response to being pushed
into new spheres and usage models, this sometimes requires big
refactoring to open the news ways of using it, but often a little
tweak here or there can deliver a lot.
I haven't fully got my head around your usage model, so I'd suggest
writing an example that could go in OpenSceneGraph/examples that
illustrates what you are trying to do, but its failing. This example
could then be used by others to see the problem first hand and then a
solution could be found, but it a tweak to the example or a tweak to
osgViewer itself.
Robert.
My guess is that this should probably be possible given separate
threads for each of the viewers frame loops i.e. run them all in a
background thread. Sharing of images is possible by using a frame
buffer copy to osg::Image, or just having multiple FBO's all within
one graphics context. If you can have the frames all done
synchronously then perhaps you could have one frame loop and just
disable the cameras that you don't need updating on each frame, i.e.
main viewer runs at 60Hz, and the other RTT cameras run at 20Hrz so
get update on frame in 3.
camera->setNodeMask(0x0);