Hi Chris,

Thanks for the explanation.

Rather than answer your questions.  I'll dive in make my own suggestion.

First up I'd create a single graphics context, this can would be a pbuffer
in your case.  This graphics context would live for life of the application.

Second I'd have a single CompositeViewer that lives throughout your

I'd then have a working set of View's that share the scene graph, and share
the same graphics context.  All these Views would be added to the
CompositeView.  At start up these View's would be disabled by setting their
View Camera's NodeMask to 0x0.

When you need to render a View for a client you'd enable a View of one is
attached and not enabled, enable by setting the Camera's NodeMask to
0xffffffff.  If you run out of View then simply create a new one for the
purpose.  Potentially you could do this on demand - so have none at start

When you no longer need a View you could remove it, but it's lighter to
just disable it via the NodeMask trick.

With this approach you aren't creating/deleting graphics contexts, will
lower memory usage and you'll get better performance.

If you have multiple graphics cards then you could create a pbuffer on each
of them and us this as part of your working set, loading balancing so the
actively View's are evenly distributed across the cards available.


On 11 September 2013 17:52, Chris Stankevitz <chrisstankev...@gmail.com>wrote:

> On Wed, Sep 11, 2013 at 9:31 AM, Robert Osfield
> <robert.osfi...@gmail.com> wrote:
> > What stands out is that you are doing stuff that is probably not the best
> > way to do it.  To find out the best way it would be better to explain
> what
> > you are tying to do with your application w.r.t views, graphics contexts,
> > threads, scenes and then let us suggest what to do.
> Fair enough.  Thank you for your patience and assistance.  My
> application is quite simple.
> I have a scene that contains a terrain, imagery overlayed atop the
> terrain, and some objects wandering around on the terrain.  I create
> this scene using osgEarth (osgEarth::Map, osgEarth::MapNode, etc).
> I'll call this the "Load" operation.
> Initially I have zero viewers.  However, from time to time I am
> notified (via a network connection) that someone wants to view the
> scene.  When this happens I create a Viewer and attach the scene data.
>  I use a pbuffer and associated callbacks to produce a JPG of the
> scene and send the video back via the network connection.  I'll call
> this the "NewViewer" operation.
> Via the network the I am told where this viewer is and which way he is
> looking.  I forward this information to the camera via a very simple
> manipulator that is attached to my view.  I'll call this the
> "MoveCamera" operation.
> Via the network I am told that a viewer is no longer interested in
> existing.  I remove the viewer.  I'll call this the "DeleteViewer"
> operation.
> Pseudocode:
> main()
> {
>   osg::ref_ptr<osg::Node> pNode = Load();
>   osg::ref_ptr<osgViewer::CompositeViewer> pCompositeViewer = new ...;
>   vector<osg_ref_ptr<osgViewer::Viewer> > Viewers;
>   while (true)
>   {
>     while (PendingNewViewer)
>     {
>       Viewers.push_back(NewViewer(pCompositeViewer));
>     }
>     while (PendingDeleteViewer)
>     {
>       DeleteViewer(pCompositeViewer, Viewers);
>     }
>     for (auto pViewer : Viewers)
>     {
>       MoveCamera(pViewer);
>     }
>    if (!Viewers.empty())
>     {
>       pCompositeViewer->frame();
>     }
>   }
> }
> ===
> Questions:
> Q0: Is this a reasonable use of OSG?
> Q1: Should I use a composite viewer (as shown in the pseudocode) or
> just "many viewers each attached to the same pNode"?
> Q2: Should this work when there are zero viewers at startup?
> Q3: Should this work as the number of viewers changes, e.g. from 0->2->0->4
> A3: No.  Not when you use a composite viewer.  The scene turns
> "purple" with this pseudocode.
> Thank you,
> Chris
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
osg-users mailing list

Reply via email to