Thanks Robert.
I just realized that the modification to osgViewer::Viewer is not
actually required to reproduce the problem in the osgviewer application
since there are no update callbacks installed anyway. Originally, I
could not get the behavior to happen in the unmodified osgviewer
application, but I just tried again and the unmodified osgviewer
application (when run with --run-on-demand dumptruck.osgt) did exhibit
the problem after I played with it for a while.
Toggling the stats viewer while manipulating the model via right click
and drag may increase the probability of triggering the behavior.
Sorry for my confusion,
Judson
On 5/23/2013 2:34 PM, Robert Osfield wrote:
Thanks for the code reproducing the problem, I'm just turning in for
the day so will have a look at trying to reproduce the issue tomorrow.
On 23 May 2013 18:32, Judson Weissert <[email protected]> wrote:
Robert,
I figured out why my case diverges from the osgviewer application. I
override osgViewer::Viewer::checkNeedToDoFrame(), member function, and call
eventTraversal() on a code path where it would otherwise not be called.
Specifically, I don't want the default behavior where a new frame is
scheduled if the camera has an update callback, or the scene has update
callbacks associated with it.
The attached patch contains a modification to
osg/applications/osgviewer/osgviewer.cpp that exposes the problem I ran
into. Notice that the checkNeedToDoFrame() implementation is exactly the
same as it exists in osgViewer::Viewer except for the 3 lines that were
removed via the #if 0 macro.
After applying the patch, I recompiled and ran:
osgviewer --run-on-demand --SingleThreaded --screen 1 spaceship.osgt
Throwing the model with the middle or right mouse button will occasionally
cause the model to disappear. Granted, it does not reproduce every time.
Right clicking and dragging horizontally seems to be the best way to
reproduce the behavior (sometimes right clicking over and over while
dragging).
I guess I need to figure out a different way to prevent frames from being
scheduled when update callbacks are present?
Thanks again,
Judson
On 5/23/2013 3:30 AM, Robert Osfield wrote:
Hi Judson,
Great detective work. The change to the frame() was done to avoid
issues with events being given times that aren't in sequence -
previously we'd get time delta's that could be negative.
Do you have an idea of how to reproduce the problem now? Once I can
reproduce it I'll be able to work out the best west to resolve the
problem.
Robert.
On 22 May 2013 22:50, Judson Weissert <[email protected]> wrote:
Robert,
I found the revision that caused the regression. Ironically, it occurred
way
before the 3.1.6 release...
See r13092 associated with
http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk/src/osgViewer/Viewer.cpp
The 3.1.2 behavior returned when I reverted that revision. A notable
behavior change that I noticed is that before I reverted r13092, the
OSG_INFO<<"Reset event time from ..." line in EventQueue::takeEvents()
would
trigger extremely often (e.g., while hovering over the viewer window). It
does not trigger at all after I reverted r13092.
See also the cutOffTime variable in Viewer::eventTraversal() which
explains
the link to ON_DEMAND frame scheduling.
Do you happen to know the original intention of r13092? The log message
is
"Moved the frame() event into the event traversal after then events and
their state have been accumulated."
Thanks for the help,
Judson
On 5/22/2013 3:02 PM, Judson Weissert wrote:
Robert,
I have made some progress. The problem appears to be caused by an
eventTimeDelta of zero which is calculated within
StandardManipulator::performMovement(). It eventually results in a
divide by
zero and the propagation of non-finite value(s) through the remainder of
the
call chain. Specifically, dy in OrbitManipulator::zoomModel() and
OrbitManipulator::panModel() ends up being a non-finite value.
Thus, I have found an explanation for the symptoms, but I have not
tracked
down the underlying cause of eventTimeDelta being calculated as zero.
Therefore, I have not been able to create a small example case yet.
Regards,
Judson
On 5/22/2013 2:37 PM, Robert Osfield wrote:
Hi Judson,
It's a curious set of circumstances but as yet I can't think of a
specific cause.
Is there any chance you can create a small example that illustrates
the problem so that I can try it out and see if I can spot the
problems.
Cheers,
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
*Judson Weissert* | Software Engineer
*Baker Hughes* | Pressure Pumping
Office: +1 724 224 1440 | Fax: +1 724 224 1442
[email protected] <mailto:[email protected]> |
[email protected] <mailto:[email protected]>
http://www.mfrac.com | /A Global Leader in Hydraulic Fracturing Software/
http://www.bakerhughes.com | /Advancing Reservoir Performance/
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
