Paul Martz wrote:
It's really implementation dependent. The NVIDIA OpenGL driver on Windows,
for example, allows you to issue a certain number of SwapBuffers calls
before it blocks. I think the default is 2 calls, but this is controllable
with a driver setting and can be as high as 10 (I
Paul Martz wrote:
Vsync is usually on by default, can be toggled on or off by some driver
options, and can also sometimes be toggled by OpenGL extensions.
but does this mean that if I call rendering blocks unti the next vsync
clock tick?
Akos
___
Robert Osfield wrote:
And frame itself is bascially just a call to advance(),
eventTraversal(), updateTraversal() and renderTraversals() so can be
rewritten long hand:
while(viewer.done())
{
viewer.advance();
viewer.eventTraversal();
viewer.updateTraversal();
Robert Osfield wrote:
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.
you mentioned vsync several times in this discussion. can you elaborate,
how this is turned on?
I understand what you're saying is that there's a
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
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
this must be the lamest question, but I don't really find an answer on
the OSG Trac wiki..
when I use Viewer (from code), how do I change the ambient light from
light blue to something else?
also, when I rotate objects, they look different from the 'back' - may
this be because of the default
Robert Osfield wrote:
viewer.getCamera()-setClearColor(Vec4(r,g,b,a));
thanks! this works!
also, when I rotate objects, they look different from the 'back' - may
this be because of the default lighting?
I don't know what you mean.
see the attached files.
front.png - a view from the
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
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
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
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
12 matches
Mail list logo
