[osg-users] Fwd: Check paging status

[Hannes Naude]

Thanks Mike, that got me on the right track.

And for the benefit of future users with similar questions, I would just
add that the osgautocapture example provides a nice example of how to use
the osgDB::DatabasePager class that Mike refers to, to achieve exactly this.

Regards
Hannes


-- Forwarded message --
From: Mike Connell <michael.conn...@gmail.com>
Date: Mon, Jun 19, 2017 at 7:24 PM
Subject: Re: [osg-users] Check paging status
To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org>


osgDB::DatabasePager : getFileRequestListSize(),
getDataToCompileListSize(), getDataToMergeListSize(),
getRequestsInProgress() and perhaps a call to requiresUpdateSceneGraph()
should get you there.

/Mike

On 19 June 2017 at 15:11, Hannes Naude <naude...@gmail.com> wrote:

> Hi all
>
> I am using OSG and osgEarth in a simulation where a lot of data is being
> loaded. Now, the normal behaviour is to load resources in separate
> background threads, so that the rendering thread does not stutter when
> large resources are being loaded. However, in my use case fidelity is more
> important than real-time behaviour. I would prefer if I could somehow check
> the status of the resource paging and only continue rendering when all
> resources have been loaded. I have browsed the examples and did some
> Googling, but could not find anything that appears directly related. If
> someone could point me toward an applicable tut/example/ or part of the
> API, it would be greatly appreciated.
>
> Regards
> Hannes Naude
>
> ___
> 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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Check paging status

[Hannes Naude]

Hi all

I am using OSG and osgEarth in a simulation where a lot of data is being
loaded. Now, the normal behaviour is to load resources in separate
background threads, so that the rendering thread does not stutter when
large resources are being loaded. However, in my use case fidelity is more
important than real-time behaviour. I would prefer if I could somehow check
the status of the resource paging and only continue rendering when all
resources have been loaded. I have browsed the examples and did some
Googling, but could not find anything that appears directly related. If
someone could point me toward an applicable tut/example/ or part of the
API, it would be greatly appreciated.

Regards
Hannes Naude
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Recommended way to render a scene from multiple independent viewpoints

[Hannes Naude]

Robert

Thanks so much for your help. That makes a lot of sense. I'll go implement
the approach where the traversal is stopped at the shared subgraph root.

Regards
Hannes

On Tue, Apr 11, 2017 at 8:08 PM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> HI Hannes,
>
> The osgViewer has a mechanism for avoid multiple traversals of shared
> scene graphs if mutlple View's share the same root node of the scene
> graph.  If shared component isn't the topmost node then the OSG has no
> straight forward way to know whether a subgraph has been traversed or
> not that frame.  One could implement a mechanism to avoid this
> visiting a node multiple times in one frame but it would be really
> costly to do, an expense that would only be a benefit for a very small
> number of users, but would slow performance for everyone else.
>
> The most efficient way to avoid this multiple traversals issue is to
> implement to have a custom callback that is tailored to the specific
> usage case that a user has.  I don't know enough about the specific
> callbacks and scene graph set up you have so I can't pinpoint the best
> route.
>
> If you have a shared subgraph that you don't want traversed multiple
> times per frame then use an UpdateCallback that has a frameNumber
> member variable that keep track of the the frameNumber (use
> NodeVisitor::getFrameStamp()'s FrameNumber) of the last traversal,
> when a traversal calls the update callback you only traverse the
> subgraph if the frameNumber is different and then set the frameNumber
> to the present frame,  if the frameNumber is the same then you just
> return immediately.  This custom UpdateCallback you'd place as high as
> you can in your scene graph to make sure the traversal stops as soon
> as possible.
>
> Another approach is to move this frameNumber tracking into your
> existing update callbacks, and simple return right away with the
> frameNumber is the same.  This requires a small tweak to the callbacks
> but is such a small change it's generally pretty easy to integrate.
>
> Finally you can simple make your callbacks resilient so that the are
> no ill effects from being called multiple times.
>
> Robert.
>
> On 11 April 2017 at 18:48, Hannes Naude <naude...@gmail.com> wrote:
> > Thanks Riccardo and Robert for your inputs.
> >
> > Robert, yes you are correct that the only issue I had with the
> > CompositeViewer was that the same Node's callback would get called as
> many
> > times as views that it appeared in. This means that for example if I
> have a
> > simple update that would translate a node a fixed amount, then nodes that
> > appear in mulitple views would move faster than those that appear in a
> > single view only. Also, as I add more cameras nodes end up moving faster.
> >
> > Obviously I can fix this in the update callback itself, by checking
> > something like simulationTime (and I would ultimately have to do this
> anyway
> > to make my motion happen at the same speed, irrespective of frame rate),
> but
> > I would prefer to not have the callbacks called at all when not required.
> >
> > Incidentally, I found that the (non-composite) viewer did not immediately
> > solve this. It would only go away if all my cameras shared the exact same
> > root node. Now I have some symbology that I wish to display on one
> camera,
> > but not the others, but I managed to achieve this by setting the nodemask
> > appropriately.
> >
> > I am not really doing anything fancy with the callbacks. I created a
> class
> > which extends osg::Callback and overrode the run method to update a
> > MatrixTransform node (via getMatrix and setMatrix). I then created
> another
> > class which extends MatrixTransform and in the constructor I call
> >
> > this->setUpdateCallback
> >
> > providing an instance of my callback class as the argument. Now whenever
> I
> > add an instance of my MatrixTransform class to the scenegraph, it
> implements
> > the motion I want.
> >
> > This seems to work, except for the multiple update problem.
> >
> > Hannes
> >
> >
> > On Tue, Apr 11, 2017 at 3:09 PM, Robert Osfield <
> robert.osfi...@gmail.com>
> > wrote:
> >>
> >> HI Hannes,
> >>
> >> The CompositeViewer was written specifically for your usage case -
> >> i.e. multiple Views.
> >>
> >> I wouldn't recommend using slave Camera's for doing multiple views,
> >> while possible it's just a mess in terms of management.  slave
> >> Camera's are tools for helping rendering a single view, but with a
> >> view that is composed o

Re: [osg-users] Recommended way to render a scene from multiple independent viewpoints

[Hannes Naude]

Thanks Riccardo and Robert for your inputs.

Robert, yes you are correct that the only issue I had with the
CompositeViewer was that the same Node's callback would get called as many
times as views that it appeared in. This means that for example if I have a
simple update that would translate a node a fixed amount, then nodes that
appear in mulitple views would move faster than those that appear in a
single view only. Also, as I add more cameras nodes end up moving faster.

Obviously I can fix this in the update callback itself, by checking
something like simulationTime (and I would ultimately have to do this
anyway to make my motion happen at the same speed, irrespective of frame
rate), but I would prefer to not have the callbacks called at all when not
required.

Incidentally, I found that the (non-composite) viewer did not immediately
solve this. It would only go away if all my cameras shared the exact same
root node. Now I have some symbology that I wish to display on one camera,
but not the others, but I managed to achieve this by setting the nodemask
appropriately.

I am not really doing anything fancy with the callbacks. I created a class
which extends osg::Callback and overrode the run method to update a
MatrixTransform node (via getMatrix and setMatrix). I then created another
class which extends MatrixTransform and in the constructor I call

this->setUpdateCallback

providing an instance of my callback class as the argument. Now whenever I
add an instance of my MatrixTransform class to the scenegraph, it
implements the motion I want.

This seems to work, except for the multiple update problem.

Hannes


On Tue, Apr 11, 2017 at 3:09 PM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> HI Hannes,
>
> The CompositeViewer was written specifically for your usage case -
> i.e. multiple Views.
>
> I wouldn't recommend using slave Camera's for doing multiple views,
> while possible it's just a mess in terms of management.  slave
> Camera's are tools for helping rendering a single view, but with a
> view that is composed of several components - either spread across
> multiple windows, or a view that requires multiple passes such as
> distortion correction, field of view etc.
>
> The only reason you drawback you state about using CompositeViewer is
> multiple update traversals. Is this correct?  If so then the
> discussion should be about what problems you are having with
> callbacks, as the solution will likely related to how you are doing
> callbacks rather high level viewer configuration.
>
> Robert.
>
> On 11 April 2017 at 12:08, Hannes Naude <naude...@gmail.com> wrote:
> > Hi all
> >
> > I am trying to render a single scene from multiple viewpoints. I
> initially
> > implemented this with a compositeviewer as per the osgthirdpersonview
> > example. This worked fine except that my update callbacks appeared to be
> > getting called more than once per render cycle. I assumed that the update
> > traversal was being done for each view separately and therefore nodes
> that
> > are present in multiple views will have their update callbacks called
> > multiple times. So, at this point I tried to do the same thing but with a
> > single View, somewhat similar to the osgCamera example. But, I do not
> want
> > to add my cameras with viewer.addSlave as I want them to move
> independently
> > of one another. So I tried adding them into the scene graph and giving
> each
> > their own GraphicsContext, but even though the windows corresponding to
> > these GraphicsContexts get created, it appears as if all rendering is
> done
> > in a single window with multiple viewpoints being rendered over one
> another.
> >
> > Obviously there are many ways to skin this cat, but I would appreciate
> some
> > guidance on the recommended approach. To recap my requirements are :
> >  - Multiple cameras viewing the same scene.
> >  - Camera positions and orientations must be independently controlled.
> >  - Node update callbacks should be called only once per Node per render
> > cycle.
> >
> > Any help will be appreciated
> >
> > Regards
> > Hannes Naude
> >
> > ___
> > 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Recommended way to render a scene from multiple independent viewpoints

[Hannes Naude]

I think I solved my own problem. I was planning to use

viewer.addSlave(cam,...)


and then use

cam->setReferenceFrame(osg::Transform::ABSOLUTE_RF)


to decouple the slave camera from the master. (If this is not the best
approach, I would still like to hear, but it seems pretty clean)

It turned out that I did not even need the second call. I think this is
because I have an update callback attached to each of the slave cameras
that explicitly sets the view matrix to match the world-to-local matrix of
some node in the scenegraph and thereby overrides the slaving.

By the way, this is something else that has bothered me. The requirement
for a camera to track a node in the scenegraph seems like it should be
extremely common. But in order to implement this I had to write my own
little NodeTracker Callback as follows:

class NodeTracker : public NodeCallback

{

public:

   NodePath _nodepath;


   NodeTracker(Node* node):_nodepath(node->getParentalNodePaths()[0]){}


   virtual void operator()(Node* node, NodeVisitor* nv)

   {

 ref_ptr cam=node->asCamera();

 if(cam)

 {

 Matrix mat2=cam->getViewMatrix();

 Matrix mat=computeWorldToLocal(_nodepath);

cam->setViewMatrix(mat);

 }

 traverse(node, nv);

   }

};

It feels like this is such a common requirement that something like it
should be built into OSG. I had a look at the tutorial on the subject :

http://trac.openscenegraph.org/projects/osg//wiki/Support/Tutorials/CameraControlNodeFollowing

but it recommends a solution that seems even more generally useful and is
quite verbose, yet is not included in osg. What am I missing here?

Regards
Hannes Naude


On Tue, Apr 11, 2017 at 1:08 PM, Hannes Naude <naude...@gmail.com> wrote:

> Hi all
>
> I am trying to render a single scene from multiple viewpoints. I initially
> implemented this with a compositeviewer as per the osgthirdpersonview
> example. This worked fine except that my update callbacks appeared to be
> getting called more than once per render cycle. I assumed that the update
> traversal was being done for each view separately and therefore nodes that
> are present in multiple views will have their update callbacks called
> multiple times. So, at this point I tried to do the same thing but with a
> single View, somewhat similar to the osgCamera example. But, I do not want
> to add my cameras with viewer.addSlave as I want them to move independently
> of one another. So I tried adding them into the scene graph and giving each
> their own GraphicsContext, but even though the windows corresponding to
> these GraphicsContexts get created, it appears as if all rendering is done
> in a single window with multiple viewpoints being rendered over one another.
>
> Obviously there are many ways to skin this cat, but I would appreciate
> some guidance on the recommended approach. To recap my requirements are :
>  - Multiple cameras viewing the same scene.
>  - Camera positions and orientations must be independently controlled.
>  - Node update callbacks should be called only once per Node per render
> cycle.
>
> Any help will be appreciated
>
> Regards
> Hannes Naude
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Recommended way to render a scene from multiple independent viewpoints

[Hannes Naude]

Hi all

I am trying to render a single scene from multiple viewpoints. I initially
implemented this with a compositeviewer as per the osgthirdpersonview
example. This worked fine except that my update callbacks appeared to be
getting called more than once per render cycle. I assumed that the update
traversal was being done for each view separately and therefore nodes that
are present in multiple views will have their update callbacks called
multiple times. So, at this point I tried to do the same thing but with a
single View, somewhat similar to the osgCamera example. But, I do not want
to add my cameras with viewer.addSlave as I want them to move independently
of one another. So I tried adding them into the scene graph and giving each
their own GraphicsContext, but even though the windows corresponding to
these GraphicsContexts get created, it appears as if all rendering is done
in a single window with multiple viewpoints being rendered over one another.

Obviously there are many ways to skin this cat, but I would appreciate some
guidance on the recommended approach. To recap my requirements are :
 - Multiple cameras viewing the same scene.
 - Camera positions and orientations must be independently controlled.
 - Node update callbacks should be called only once per Node per render
cycle.

Any help will be appreciated

Regards
Hannes Naude
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Fwd: OSG performance measurement

[Hannes Naude]

Hi Robert

Thanks for the reply. I toggled on the high levels of stats info and it was
immediately apparent that the delays were occurring in the event traversal,
which made no sense, since the only eventhandler that I explicitly added is
the StatsHandler and the problem predates that.

At this point, I abandoned my strong preconception that the problem was
somewhere in my OSG calling code or in the way that I set up my project and
just used htop to see whether any other processes were starving my little
OSG program of CPU time (something I did not consider earlier, because of
mentioned preconceptions and the fact that everything else running on my PC
appears responsive.) I saw a bunch of java processes that were hogging the
CPU (Attempts to install a newer eclipse via yatta that had failed silently
a few days ago). After killing these, the framerate went up to 60Hz and
stayed there after I uncommented all the actual functionality in my
program. So this was not OSG related at all after all. :-O

Thanks for your help.

Regards
Hannes

On Mon, Oct 17, 2016 at 5:18 PM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Hi Hannes,
>
> There really isn't much info to go on from what you are written so
> far.  Using the StatsHandler is a good first step but just the frame
> rate reports doesn't tell us enough to know what is going on.
>
> Try toggling the the high levels of stats info and then look at the
> size of the update, event, cull, draw dispatch and draw GPU.
>
> Another thing to do is switch off vsync via the driver and see what
> the framerate is without vysunc on.
>
> Try with a range a models.  As a general note, the OSG with 980Ti
> should perform pretty well even for very large models.  I develop
> under Kubuntu and find the NVidia drivers work pretty well, it has to
> be a pretty serious model to get the frame rate down as low as
> 30-40fps, this requires ten's of millions of vertices per frame to be
> rendered or high res volume rendering.  With an small scene such as
> the OpenSceneGraph-Data's cow.osgt I get 6000+fps on a 1920x1080
> display.
>
> Robert.
>
> On 17 October 2016 at 16:05, Hannes Naude <naude...@gmail.com> wrote:
> > OK. Scratch that, I no longer believe that this is a performance
> measurement
> > issue, but rather a performance issue. I have replaced my measurement
> code
> > with the built in StatsHandler class, so my code now looks as follows:
> >
> > int main() {
> > ref_ptr viewer=new
> osgViewer::CompositeViewer();
> > ref_ptr view1 = new osgViewer::View;
> > viewer->addView(view1);
> > view1->addEventHandler( new osgViewer::StatsHandler );
> > return viewer->run();
> > }
> >
> > When I press S statshandler reports 30-40fps. Obviously there is not a
> lot
> > of room to have messed up in a 5-liner program, so I believe that that is
> > the actual framerate that I am getting. Question is why. I am running on
> a
> > NVIDIA Geforce 980Ti under Ubuntu 14.04 with nvidia driver version
> 352.63) .
> > I have optimization on (-O3 under gcc)  and believe that I am linking
> > against release libraries not debug ones.
> >
> > Any ideas where to look??
> >
> > Regards
> > Hannes
> > -- Forwarded message --
> > From: Hannes Naude <naude...@gmail.com>
> > Date: Mon, Oct 17, 2016 at 1:46 PM
> > Subject: OSG performance measurement
> > To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org>
> >
> >
> > Hi all
> >
> > New to OSG so apologies if this is a stupid question.
> >
> > I have written a visualization tool in OSG and as a last step, I wish to
> > ensure that it runs at the screen refresh rate. My perception was that it
> > mostly runs smoothly but stutters every few frames or so, so I wrote
> code to
> > print the elapsed time between every two frames, rather than just the
> > average framerate. The printout seemed to confirm this, so I gradually
> > removed more and more of my scenegraph, trying to determine where the
> > bottleneck lies. The weird thing is that I end up with a completely empty
> > scenegraph (just rendering a blue screen) and execution time STILL seems
> to
> > stutter. So, I strongly suspect that there is something fundamentally
> wrong
> > with the way I am measuring. I realise that FPS is a bad performance
> metric,
> > but right now I just want to get to the point where I am updating every
> > frame on my hardware and I am not particularly concerned about
> performance
> > on any other hardware. The remaining code looks like this:
> >
> > int main() {
> > ref_ptr viewer=new
> osgViewer::CompositeVi

[osg-users] Fwd: OSG performance measurement

[Hannes Naude]

OK. Scratch that, I no longer believe that this is a performance
measurement issue, but rather a performance issue. I have replaced my
measurement code with the built in StatsHandler class, so my code now looks
as follows:

int main() {
ref_ptr viewer=new osgViewer::CompositeViewer();
ref_ptr view1 = new osgViewer::View;
viewer->addView(view1);
view1->addEventHandler( new osgViewer::StatsHandler );
return viewer->run();
}

When I press S statshandler reports 30-40fps. Obviously there is not a lot
of room to have messed up in a 5-liner program, so I believe that that is
the actual framerate that I am getting. Question is why. I am running on a
NVIDIA Geforce 980Ti under Ubuntu 14.04 with nvidia driver version 352.63)
. I have optimization on (-O3 under gcc)  and believe that I am linking
against release libraries not debug ones.

Any ideas where to look??

Regards
Hannes
-- Forwarded message --
From: Hannes Naude <naude...@gmail.com>
Date: Mon, Oct 17, 2016 at 1:46 PM
Subject: OSG performance measurement
To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org>


Hi all

New to OSG so apologies if this is a stupid question.

I have written a visualization tool in OSG and as a last step, I wish to
ensure that it runs at the screen refresh rate. My perception was that it
mostly runs smoothly but stutters every few frames or so, so I wrote code
to print the elapsed time between every two frames, rather than just the
average framerate. The printout seemed to confirm this, so I gradually
removed more and more of my scenegraph, trying to determine where the
bottleneck lies. The weird thing is that I end up with a completely empty
scenegraph (just rendering a blue screen) and execution time STILL seems to
stutter. So, I strongly suspect that there is something fundamentally wrong
with the way I am measuring. I realise that FPS is a bad performance
metric, but right now I just want to get to the point where I am updating
every frame on my hardware and I am not particularly concerned about
performance on any other hardware. The remaining code looks like this:

int main() {
ref_ptr viewer=new
osgViewer::CompositeViewer(); ref_ptr
view1 = new osgViewer::View;
viewer->addView(view1);
float timeNow,timePrev=0;
while (!viewer->done())
{
viewer->frame();
timeNow=osg::Timer::instance()->time_s();
std::cout << timeNow-timePrev << " ";
timePrev=timeNow;
}
return(0);
}

and the resulting printout to the console looks like this:

0.123003 0.00298501 0.000751987 0.016045 0.083418 0.038128 0.013075
0.00068298 0.014678 0.019825 0.013804 0.016688 0.01651 0.066802 0.023197
0.07995 0.013019 0.000387967 0.0331 0.000599027 0.03273 0.000575006
0.088067 0.083023...

As you can see, the loop occasionally takes as much as 88ms to complete,
while at other time completing within 0.6ms. What could possibly be causing
this massive variation?

Regards
Hannes Naude
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OSG performance measurement

[Hannes Naude]

Hi all

New to OSG so apologies if this is a stupid question.

I have written a visualization tool in OSG and as a last step, I wish to
ensure that it runs at the screen refresh rate. My perception was that it
mostly runs smoothly but stutters every few frames or so, so I wrote code
to print the elapsed time between every two frames, rather than just the
average framerate. The printout seemed to confirm this, so I gradually
removed more and more of my scenegraph, trying to determine where the
bottleneck lies. The weird thing is that I end up with a completely empty
scenegraph (just rendering a blue screen) and execution time STILL seems to
stutter. So, I strongly suspect that there is something fundamentally wrong
with the way I am measuring. I realise that FPS is a bad performance
metric, but right now I just want to get to the point where I am updating
every frame on my hardware and I am not particularly concerned about
performance on any other hardware. The remaining code looks like this:

int main() {
ref_ptr viewer=new
osgViewer::CompositeViewer(); ref_ptr
view1 = new osgViewer::View;
viewer->addView(view1);
float timeNow,timePrev=0;
while (!viewer->done())
{
viewer->frame();
timeNow=osg::Timer::instance()->time_s();
std::cout << timeNow-timePrev << " ";
timePrev=timeNow;
}
return(0);
}

and the resulting printout to the console looks like this:

0.123003 0.00298501 0.000751987 0.016045 0.083418 0.038128 0.013075
0.00068298 0.014678 0.019825 0.013804 0.016688 0.01651 0.066802 0.023197
0.07995 0.013019 0.000387967 0.0331 0.000599027 0.03273 0.000575006
0.088067 0.083023...

As you can see, the loop occasionally takes as much as 88ms to complete,
while at other time completing within 0.6ms. What could possibly be causing
this massive variation?

Regards
Hannes Naude
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org