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
