Re: [osg-users] On demand and frame rate capping schemes fromViewer::run()

2009-04-25 Thread Robert Osfield
HI Paul,

On Fri, Apr 24, 2009 at 11:53 PM, Paul Martz pma...@skew-matrix.com wrote:
 Hi Robert -- You said the code isn't final yet, but I wondered if the
 osgviewer options and environment variables are final? Or do you intend to
 remove them after development?

Subject to feedback on typos and suggestions of better naming I don't
see a reason that these new command line options and env vars would
need to be changed/removed.

It might make sense to provide a default max frame rate to cope with
systems that don't have vysnc switched on, as the user experience is
better with preventing the app spinning at a silly frame rate.  One
would need to disable this when doing certain types of benchmarking
though.

One concern about introducing a max frame rate value is that end users
we almost certainly ask when they frame rate is not scaling well... or
that OSG-2.9.x/2.10 doesn't perform as well as OSG-2.8.  This is an
education issue, and as we've found out in the past it doesn't really
matter how often you put up information, or where you put it, still
lots of users ignore it completely... so one just has to field the
support from those too lazy to keep informed.

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


Re: [osg-users] On demand and frame rate capping schemes fromViewer::run()

2009-04-25 Thread Judd Tracy
It would be nice if the stats handler could display on the screen when the
frame rate is limited and to what value.  That might help some of the people
realize that there is an artificial limitation.  And maybe it should also
report when vsync is enabled too.

On Sat, Apr 25, 2009 at 4:39 AM, Robert Osfield robert.osfi...@gmail.comwrote:

 HI Paul,

 On Fri, Apr 24, 2009 at 11:53 PM, Paul Martz pma...@skew-matrix.com
 wrote:
  Hi Robert -- You said the code isn't final yet, but I wondered if the
  osgviewer options and environment variables are final? Or do you intend
 to
  remove them after development?

 Subject to feedback on typos and suggestions of better naming I don't
 see a reason that these new command line options and env vars would
 need to be changed/removed.

 It might make sense to provide a default max frame rate to cope with
 systems that don't have vysnc switched on, as the user experience is
 better with preventing the app spinning at a silly frame rate.  One
 would need to disable this when doing certain types of benchmarking
 though.

 One concern about introducing a max frame rate value is that end users
 we almost certainly ask when they frame rate is not scaling well... or
 that OSG-2.9.x/2.10 doesn't perform as well as OSG-2.8.  This is an
 education issue, and as we've found out in the past it doesn't really
 matter how often you put up information, or where you put it, still
 lots of users ignore it completely... so one just has to field the
 support from those too lazy to keep informed.

 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


Re: [osg-users] On demand and frame rate capping schemes fromViewer::run()

2009-04-25 Thread Robert Osfield
On Sat, Apr 25, 2009 at 2:22 PM, Judd Tracy j...@thetracys.net wrote:
 It would be nice if the stats handler could display on the screen when the
 frame rate is limited and to what value.  That might help some of the people
 realize that there is an artificial limitation.  And maybe it should also
 report when vsync is enabled too.

That's a good idea.  We can't alway find out whether vsync is on
though, even if you request it to be on the driver might not implement
it.

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


Re: [osg-users] On demand and frame rate capping schemes fromViewer::run()

2009-04-24 Thread Paul Martz
Hi Robert -- You said the code isn't final yet, but I wondered if the
osgviewer options and environment variables are final? Or do you intend to
remove them after development? 


Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Friday, April 24, 2009 12:13 PM
To: OpenSceneGraph Users
Subject: [osg-users] On demand and frame rate capping schemes
fromViewer::run()

Hi All,

When following up on a bug report about the pager not handling on
demand/lazy frame rendering I resolved the the problems wasn't down to the
pager, just the way the end user viewer code was set up to the the on demand
frame rendering.  Rather than leave this type of viewer usage open to end
users come up with lots of different schemes to attempt to the same thing,
and with it the potential fall out in terms of support of trying to help
debug them I've coded up a solution for osgViewer that can either be used
directly or as a template for others to learn from.

What I have done is to refactor osgViewer::ViewerBase::run() so that it's
frame loop now has two new capabilities:

   1) On demand (lazy) frame rendering  vs Continuous frame rendering (the
original functionality, and still the default.)
   2) Optional frame rate capping to a specified maximum frame rate
(defaults to off.)

Now item 2 isn't a required for on demand frame rendering, but it more for
coping with end user system not having vsync enabled by default.
Since I was working on this piece of code I thought I'd tackle this item as
well.  The actual ViewerBase::run() method (use by both Viewer and
CompositeViewer) now looks like:


int ViewerBase::run()
{
if (!isRealized())
{
realize();
}

const char* str = getenv(OSG_RUN_FRAME_COUNT);
int runTillFrameNumber = str==0 ? -1 : atoi(str);

while(!done() || (runTillFrameNumber=0 
getViewerFrameStamp()-getFrameNumber()runTillFrameNumber))
{
double minFrameTime = _runMaxFrameRate0.0 ? 1.0/_runMaxFrameRate :
0.0;
osg::Timer_t startFrameTick = osg::Timer::instance()-tick();
if (_runFrameScheme==ON_DEMAND)
{
if (checkNeedToDoFrame()) frame();
}
else
{
frame();
}

// work out if we need to force a sleep to hold back the frame rate
osg::Timer_t endFrameTick = osg::Timer::instance()-tick();
double frameTime =
osg::Timer::instance()-delta_s(startFrameTick, endFrameTick);
if (frameTime  minFrameTime)
OpenThreads::Thread::microSleep(100.0*(minFrameTime-frameTime));
}

return 0;
}

The code isn't final yet, but is certainly good enough for us to start
testing.  You can test it by setting the env vars:

   OSG_RUN_FRAME_SCHEME=ON_DEMAND

or go back to default

   OSG_RUN_FRAME_SCHEME=CONTINUOUS

And

   OSG_RUN_MAX_FRAME_RATE=60.0

or switch off and the default

   OSG_RUN_MAX_FRAME_RATE=0.0


You can also use the following command line options:

  osgviewer cow.osg --run-on-demand

  osgviewer cow.osg --run-continuous

  osgviewer cow.osg --run-continuous  --run-max-frame-rate 30.0


The on demand frame rendering does already support paged databases, and I've
updated various event handles to manually do a
requestRedraw() which prompts the viewer::run() to rendering a new
frame.   What I have got working yet is handling of the update visitor
doing updates. so on demand rendering just freezes things like particle
systems and animations till you move the eye point, trigger an event.  I'll
have a look at support event callbacks next.

Please note this support only affect viewer::run() it doesn't effect apps
that roll their own frame loop.

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