Thanks a lot for your answer, now I understand a bit of what is going on...
I will write the example for better understanding of what I am trying to do
and look at the code you suggested.
I'll derive it from the code in osgwindows (setting one camera for each
window in an independent viewer) and
post it here as soon as possible.
Just in case you are curious about my case of use, I will try to explain a
bit my intentions, if you consider that my
approximation is not right please correct me.
I am building a simulation framework aimed at multi-robot collaborative
perception. I am going to implement this
using a composite viewer with at least two views for the simulator user
interface, plus a dynamic number of viewers,
one for each simulated camera as I need to be able to set the frame rate of
the cameras independently.
The cameras of these viewers would render to a pbuffer each and have an
image attached in order to send then to the
artificial vision algorithms. I also need to share the scene across all the
viewers.
Thanks,
Nicolas
.
2008/2/24, Robert Osfield <[EMAIL PROTECTED]>:
>
> HI Nicolas,
>
>
> On Fri, Feb 22, 2008 at 7:11 PM, nicolas peña <[EMAIL PROTECTED]>
> 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.
>
> _______________________________________________
> 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
