Re: [osg-users] OSG CPU usage
Mario Valle wrote:
Look at the following code (Refresh fires OnPaint that fires viewer-frame())
void Canvas::OnIdle(wxIdleEvent event)
{
if (_updateWhenIdle || _updateWhenIdleOverride)
{
Refresh();
event.RequestMore();
}
}
Without this logic the viewer was continually spinning.
I see, but these are not OSG calls, but wxWindows calls.
is it so that one cannot achieve this functionality with OSG, but has to
look outside to a windowing API?
Akos
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG CPU usage
Mario Valle wrote: No, methods from TrackballManipulator help you in understanding when you are interacting with the viewer and so when you need to call frame(). I'm looking at it, it's in the Canvas class, which is a descendant of wxGLCanvas - which is not an OSG class, or is it? Akos ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG CPU usage
Look at the following code (Refresh fires OnPaint that fires viewer-frame())
void Canvas::OnIdle(wxIdleEvent event)
{
if (_updateWhenIdle || _updateWhenIdleOverride)
{
Refresh();
event.RequestMore();
}
}
Without this logic the viewer was continually spinning.
Hope it helps
mario
Ákos Maróy wrote:
Mario Valle wrote:
The recently posted wxTabbed example has a method to block update till
they are needed. Look at it.
do you mean the sample in this message:
http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2007-October/003972.html
?
I glanced at it, but the 'block until updated needed' aspect of the code
sample wasn't obvious :(
Akos
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Ing. Mario Valle
Visualization Group | http://www.cscs.ch/~mvalle
Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60
v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG CPU usage
No, methods from TrackballManipulator help you in understanding when you are
interacting
with the viewer and so when you need to call frame().
Ciao!
mario
Ákos Maróy wrote:
Mario Valle wrote:
Look at the following code (Refresh fires OnPaint that fires viewer-frame())
void Canvas::OnIdle(wxIdleEvent event)
{
if (_updateWhenIdle || _updateWhenIdleOverride)
{
Refresh();
event.RequestMore();
}
}
Without this logic the viewer was continually spinning.
I see, but these are not OSG calls, but wxWindows calls.
is it so that one cannot achieve this functionality with OSG, but has to
look outside to a windowing API?
Akos
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Ing. Mario Valle
Visualization Group | http://www.cscs.ch/~mvalle
Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60
v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG CPU usage
Thibault, Thanks for the detailed explanation. Now it's quite clear now.. Akos ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG CPU usage
Mario Valle wrote: The recently posted wxTabbed example has a method to block update till they are needed. Look at it. do you mean the sample in this message: http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2007-October/003972.html ? I glanced at it, but the 'block until updated needed' aspect of the code sample wasn't obvious :( Akos ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG CPU usage
On Nov 15, 2007 7:16 PM, Bob Kuehne [EMAIL PROTECTED] wrote: we'll have to agree to disagree. i think rendering when data hasn't changed is a bad use of system resources. what matters ultimately isn't frame-rate, but _perceived_ frame-rate, and if the user is staring at an immobile object from an immobile view, 60Hz is no better than 1Hz. In a simulator you don't have generally static views scenes, and you absolutely have to hit vsync, no frame drops or the suspension of disbelief is broken. Assuming that starting and stopping a sim visual update on demand is OK is very bad assumption, things like usleep and similiar tricks aren't at all reliable enough, as soon as you hand over responsibility for frame scheduling to something else that is schedule by the operating system or ever work windowing toolkit you have given any hope of determinism, you are in the lap of the gods whether you hit frame or not. Not to mention all the other issues associated with paging, animations and physics simulations... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG CPU usage
On Nov 16, 2007 5:31 PM, Paul Martz [EMAIL PROTECTED] wrote: In a dedicated flight sim, I tend to agree with you. Go ahead and let it continuously redraw the scene, even if it is static -- the processor isn't used for anything else anyway. But for any type of desktop/PC rendering application, users expect the CPU to be free for other tasks when they pause or stop the animation. As long as vsync is on, as it should almost should be then the CPU load shouldn't be overwhelming with a standard frame loop. In my experience, dedicated rendering loops have actually generated end-user bug reports, claiming the CPU was occupied even when they had stopped the animation. After I modified the app to only render when needed, never once did I receive a single bug report along the lines of this wrecked my suspension of disbelief. Desktop users might not worry about an occassional dropped frame, proper sims though, if you don't hit a solid 60Hz (or whatever vsync is) then you will find users feeling nauseous or suffering from undue fatigue, but they won't neccessarily know why - one of the reasons for this is inconsistent/juttery framerate. The more immersive the simulator the more critical this issue is. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG CPU usage
Hi Akos The Canvas class derives from wxGLCanvas, and is the glue between the OSG and wxWidgets. It defines two child classes: View and GraphicsContext. Canvas::GraphicsContext derives from osgViewer::GraphicsWindow (pure virtual). The OSG uses the GraphicsWindow to actually create the window, showing it and query its status. There is not much to do in the wxWidgets situation because the window itself is the Canvas. The Canvas *could* have derived from both wxGLCanvas and osgViewer::GraphicsContext, but since wxWidgets does not like multiple inheritance for controls, I have chosen to create the child class Canvas::GraphicsContext that mostly forwards the call to the Canvas. This is also why the Canvas::GraphicsContext is private - the user does not need to care about it. Canvas::View derives from osgViewer::View (pure virtual too). An OSG window can display multiple, independent views. The camera, manipulators and all other view-dependent features are part of the view. The view is also responsible for querying the graphics subsystem to redraw the window and continuously update it. To my current understanding, only osgGA::Manipulators actually perform those queries. If your application needs it (e.g. if your physics model is dependent on the OSG update traversal) you should also request redraws/continuous updates from your OSG code. The Canvas::View respond to those requests by asking wxWidgets to redraw the window - continuously through idle events or a single time. Have a look at the headers of osgViewer::GraphicsContext and osgViewer::View to have a more in-depth understanding of their roles. The simulation problem is quite unrelated. As Robert says, a real simulation should run at a constant frame rate. If your application is not a CAD software (or alike) and always needs redraws, you can use the method Canvas::setUpdateWhenIdleOverride(true). This will continuously update the window, thereby recreating the normal OSG loop. Be certain that it will be slower than a pure OSG application, though. Thibault On Nov 16, 2007 11:58 AM, Ákos Maróy [EMAIL PROTECTED] wrote: Mario Valle wrote: No, methods from TrackballManipulator help you in understanding when you are interacting with the viewer and so when you need to call frame(). I'm looking at it, it's in the Canvas class, which is a descendant of wxGLCanvas - which is not an OSG class, or is it? Akos ___ 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] OSG CPU usage
Hello Ákos, I see... I tried to use the osgViewer::Viewer class in my application as well. how can I display my scene graph so that it is idle when there's nothing to do? If you turn on Wait for vsync in your video drivers, it will limit the frame rate of your app to the refresh rate you are running at (60HZ, 72Hz, whatever). But even then, in some graphics drivers the wait is implemented as a busy wait which will give the appearance that your app is maxing out CPU time anyways. This is just an appearance though. If you run another app you will see that your osgviewer app will still run at your monitor's refresh rate, but it will relinquish CPU time to the other app so that it runs at normal speed (as long as your osgviewer app is not CPU limited in the first place, in which case the 100% CPU usage will be from actual work, not the busy wait). Real-time Rendering by Möller and Haines is a great reference on this and other graphics topics, by the way. Good luck, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG CPU usage
Hi, I'm new to OSG.. I compiled OSG on my Linux box, and I see that any OSG application I start, it maxes out the CPU, even when seemingly it doesn't do much like I open osgviewer with a model (say cow.osg), and then don't touch the window (no rotation, zoom,etc.) - and top shows the viewer taking all my CPU time is there a specific reason for this? Akos ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG CPU usage
in fact, what paul says is very similar to what i often do in test apps:
while ( !viewer.done() )
{
usleep( timeToSleepToGetMeToMyDesiredFrameRate );
viewer.frame();
}
in a more commercial-style app, i'd recommend only redrawing when data
actually
changes. so in a cad app, when the user moves the mouse, or edits the
data, in a
flight sim, when the eyepoint, or any on-screen data changes, etc.
bob
On Nov 15, 2007, at 10:11 AM, Paul Martz wrote:
how can I display my scene graph so that it is idle when
there's nothing to do?
The osgviewer app calls viewer.run(), which is effectively the same
as:
while (!viewer.done())
viewer.frame() // draw a single frame
So, if you only want to draw when your app is not idle, then you
should not
use viewer.run(). Instead, you should call viewer.frame() only when
the
image needs to be updated.
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
303 859 9466
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
bob kuehne
founder and ceo - blue newt software
www.blue-newt.com734/834-2696
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG CPU usage
Bob Kuehne wrote: yes - osgviewer simply 'free runs', that is, renders new frames constantly, as fast as it can. hence, it's always busy doing something, even if that's just redrawing the same picture. I see... I tried to use the osgViewer::Viewer class in my application as well. how can I display my scene graph so that it is idle when there's nothing to do? Akos ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG CPU usage
Ditto Glenn's post. The big gotcha I ran into when I modified SimAuthor's
FlightViz to render only when necessary, was discovering just how much of
the application assumed and depended on a constantly-running render loop. No
doubt there are portions of OSG that also have such a dependency. For
example, isn't there a 1-frame latency in AutoTransform and Billboard?
-Paul
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Glenn
Waldron
Sent: Thursday, November 15, 2007 1:25 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OSG CPU usage
Ellery,
Be sure to account for the DatabasePager if you plan to use PagedLOD nodes.
You will have to check that the pager has no more work to do before stopping
your loop. Another thought... you may need to do something to prevent
PagedLODs from appearing to expire because the cull traversal isn't updating
their timestamps regularly...?
--
Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791
On Nov 15, 2007 2:27 PM, Ellery Chan
mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
I've tried writing a start-stop frame loop, and it seems to work fine.
You have to make sure you know when objects are moving in the scene. I
also added a periodic redraw (i used something between once a second and
once every 5 seconds) just so the app wouldn't get swapped out and have
trouble waking up quickly.
Are there any other perceptual drawbacks to the start-stop approach,
assuming you can start and stop the frame loop reliably?
-ellery-
Bob Kuehne wrote:
we'll have to agree to disagree. i think rendering when data hasn't
changed is a bad use of system resources. what matters ultimately
isn't frame-rate, but _perceived_ frame-rate, and if the user is
staring at an immobile object from an immobile view, 60Hz is no better
than 1Hz.
eof.
b
On Nov 15, 2007, at 10:43 AM, Robert Osfield wrote:
On Nov 15, 2007 3:19 PM, Bob Kuehne [EMAIL PROTECTED] wrote:
in fact, what paul says is very similar to what i often do in test
apps:
while ( !viewer.done() )
{
usleep( timeToSleepToGetMeToMyDesiredFrameRate );
viewer.frame();
}
in a more commercial-style app, i'd recommend only redrawing when
data
actually
changes. so in a cad app, when the user moves the mouse, or edits the
data, in a
flight sim, when the eyepoint, or any on-screen data changes, etc.
Yikes, I don't quite agree with this. All apps should have vysync on
for sure. Interactive apps need't run a constant frame loop - and can
just dispatch a frame when users moves the eye point, etc. However,
for simulators and games the frame loop is critical, it is what needs
to run a solid frame rate and locked to vysync, you shouldn't try to
drive simulators like interactive applications, and flight sim is a
great example of something that should run at a solid frame.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
bob kuehne
founder and ceo - blue newt software
www.blue-newt.com734/834-2696
___
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] OSG CPU usage
The recently posted wxTabbed example has a method to block update till
they are needed. Look at it.
Ciao!
mario
Ákos Maróy wrote:
Bob Kuehne wrote:
in fact, what paul says is very similar to what i often do in test apps:
while ( !viewer.done() )
{
usleep( timeToSleepToGetMeToMyDesiredFrameRate );
viewer.frame();
}
in a more commercial-style app, i'd recommend only redrawing when data
actually
changes. so in a cad app, when the user moves the mouse, or edits the
data, in a
flight sim, when the eyepoint, or any on-screen data changes, etc.
yes, I also think this is the good approach - only draw something if
something has changed.
but for the viewer, I'd need to know if there was any user input (like a
mouse operation for zooming in/out), that is handled by the viewer
itself. is there a way to catch this event? I imagine something like the
following:
while (!viewer.done()) {
blockUntilTheresChange();
viewer.frame();
}
is there something to this end in viewer?
Akos
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Ing. Mario Valle
Visualization Group | http://www.cscs.ch/~mvalle
Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60
v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
