Re: [osg-users] On demand and frame rate capping schemes from Viewer::run()
Robert,
Good stuff.Limit frame rate (ie, frame rate capping) is good. But how
about Fixed frame rate though? Where the OSG renders at a specified
frame rate no matter what.
Thanks,
Brett
Robert Osfield wrote:
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
Re: [osg-users] On demand and frame rate capping schemes from Viewer::run()
Hi Brett, On Mon, Apr 27, 2009 at 3:35 PM, brettwiesner brettwies...@gmail.com wrote: Good stuff.Limit frame rate (ie, frame rate capping) is good. But how about Fixed frame rate though? Where the OSG renders at a specified frame rate no matter what. It all depends on exactly you mean by no matter what. What are you thinking in terms of management of the scene to manage this trick? Magic? One potentially could introduce a scheme of load balancing based on LODScale that responds to frame rate load, but a scheme that works well for all types of scenes will be next to impossible to come by. We could potentially provide one that does good enough on a range of models/application, but not perfectly for all application types. There is also a real limit on how much LODScale can load balance, if the scene graph itself isn't set up well with LOD then it won't make any difference. Personally I feel that most apps should manage the frame for their own applications and data. The OSG is a general purpose scene graph rather than a domain specific IG. It gives you the tools to do your job, but it doesn't do it all for you. The run() method stuff I've introduced is really only for entry level app development. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] On demand and frame rate capping schemes from Viewer::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
Re: [osg-users] On demand and frame rate capping schemes from Viewer::run()
On Fri, Apr 24, 2009 at 8:11 PM, Roland Smeenk roland.sme...@tno.nl wrote: Interesting development. For a current project we need one view that runs at 5 Hz and several other views that run at 15 Hz (all in separate graphicscontexts). No, I am not joking. This is used to simulate real life camera behaviour. We do our own version of the frame method, but that still is too high level for achieving the required timing granularity. How about this? This type of frame rate management is well beyond what I'd expect the viewer convenience methods like run to handle. You should expect to roll your own frame management for this type of app. 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 from Viewer::run()
Interesting development. For a current project we need one view that runs at 5 Hz and several other views that run at 15 Hz (all in separate graphicscontexts). No, I am not joking. This is used to simulate real life camera behaviour. We do our own version of the frame method, but that still is too high level for achieving the required timing granularity. How about this? kind regards, Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10832#10832 ___ 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 from Viewer::run()
This type of frame rate management is well beyond what I'd expect the viewer convenience methods like run to handle. You should expect to roll your own frame management for this type of app. That's what I thought you would answer. Well, didn't hurt to try. Thanks. -- Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10836#10836 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
