Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
Hi Judson, On 29 May 2013 15:01, Judson Weissert jud...@mfrac.com wrote: My fault, I performed an invalid test. My osgviewer.cpp source was modified, and I did not realize it. It was still overriding checkNeedToDoFrame(). I retested, and it appears to be working as expected. Sorry about that. I will continue testing and report back my findings if I find anything. Good to hear it's working. With your own code with modified checkNeedToDoFrame() you will be best to either call the base classes checkNeedToDoFrame() or recreate similar code w.r.t calling the new bool checkEvents() method rather than doing a full event traversal. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
Hi Judson, On 28 May 2013 20:36, Judson Weissert jud...@mfrac.com wrote: I just got the 3.1.7 developer release built. Running the osgviewer application with arguments --run-on-demand --screen 1 dumptruck.osgt results in a regression where the viewer does not respond to mouse or keyboard input (does not render any new frames, does not allow me to exit via escape, does not respond to 's' for stats, etc). Similar behavior occurs in my application, but I have not had a chance to run the code in a debugger yet. Running the osgviewer application without the --run-on-demand flag appears to work as expected. Compiled with Visual C++ 2010, running on Windows 7 (Same machine and compiler settings as my previous tests). I just tested: osgviewer --run-on-demand --screen 0 dumptruck.osgt And it worked fine. I can't test --screen 1 I don't have a second display attached right now. I wouldn't expect this to make a difference. Could you try --screen 0? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
Robert, My fault, I performed an invalid test. My osgviewer.cpp source was modified, and I did not realize it. It was still overriding checkNeedToDoFrame(). I retested, and it appears to be working as expected. Sorry about that. I will continue testing and report back my findings if I find anything. Thanks again, Judson On 5/29/2013 4:19 AM, Robert Osfield wrote: Hi Judson, On 28 May 2013 20:36, Judson Weissert jud...@mfrac.com wrote: I just got the 3.1.7 developer release built. Running the osgviewer application with arguments --run-on-demand --screen 1 dumptruck.osgt results in a regression where the viewer does not respond to mouse or keyboard input (does not render any new frames, does not allow me to exit via escape, does not respond to 's' for stats, etc). Similar behavior occurs in my application, but I have not had a chance to run the code in a debugger yet. Running the osgviewer application without the --run-on-demand flag appears to work as expected. Compiled with Visual C++ 2010, running on Windows 7 (Same machine and compiler settings as my previous tests). I just tested: osgviewer --run-on-demand --screen 0 dumptruck.osgt And it worked fine. I can't test --screen 1 I don't have a second display attached right now. I wouldn't expect this to make a difference. Could you try --screen 0? 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] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
Robert, This is great news! I will try out the new code as soon as possible and report back my findings. Thanks, Judson On 5/24/2013 5:42 AM, Robert Osfield wrote: Hi Judson. I have refactored the Viewer/CompositeViewer::checkNeedToDo() method so that it now calls a new Viewer/CompositeViewer::checkEvents() method that checks for available events rather than rely upon the more heavier weight eventTraversals() method. The eventTraversals() method design is focused on being done as part of a full frame and was hacked to work in the case of run or demand but didn't handle me moving the frame() event generation into. There are good reasons to move frame() event, but not so good reasons to do a full event traversal as a means for checking whether a full frame is needed or not. The introduction of the checkEvents() method required quite a few changes in other classes to support it, fingers crossed I haven't broken the build in the process of making these changes, unfortunately I can't test out OSX, iOS, Windows builds so will have rely upon the community to test of these changes that I had to make to the platform specific GraphicsWindow implementations. I have now checked in my changes to svn/trunk, could you test them out and let me know if things are working OK now. Cheers, 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] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
Hi Robert, I just got the 3.1.7 developer release built. Running the osgviewer application with arguments --run-on-demand --screen 1 dumptruck.osgt results in a regression where the viewer does not respond to mouse or keyboard input (does not render any new frames, does not allow me to exit via escape, does not respond to 's' for stats, etc). Similar behavior occurs in my application, but I have not had a chance to run the code in a debugger yet. Running the osgviewer application without the --run-on-demand flag appears to work as expected. Compiled with Visual C++ 2010, running on Windows 7 (Same machine and compiler settings as my previous tests). Regards, Judson On 5/28/2013 9:39 AM, Judson Weissert wrote: Robert, This is great news! I will try out the new code as soon as possible and report back my findings. Thanks, Judson On 5/24/2013 5:42 AM, Robert Osfield wrote: Hi Judson. I have refactored the Viewer/CompositeViewer::checkNeedToDo() method so that it now calls a new Viewer/CompositeViewer::checkEvents() method that checks for available events rather than rely upon the more heavier weight eventTraversals() method. The eventTraversals() method design is focused on being done as part of a full frame and was hacked to work in the case of run or demand but didn't handle me moving the frame() event generation into. There are good reasons to move frame() event, but not so good reasons to do a full event traversal as a means for checking whether a full frame is needed or not. The introduction of the checkEvents() method required quite a few changes in other classes to support it, fingers crossed I haven't broken the build in the process of making these changes, unfortunately I can't test out OSX, iOS, Windows builds so will have rely upon the community to test of these changes that I had to make to the platform specific GraphicsWindow implementations. I have now checked in my changes to svn/trunk, could you test them out and let me know if things are working OK now. Cheers, 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
Hi Judson, On 23 May 2013 21:57, Judson Weissert jud...@mfrac.com wrote: 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. This is great news, I've just tried running osgviewer --run-on-demand as suggested and see the problem with the pan causing the view to jump off toward infinity. I can reproduce the bug consistently so there is a good chance I'll be able to home in on the issue. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
Hi Judson. I have refactored the Viewer/CompositeViewer::checkNeedToDo() method so that it now calls a new Viewer/CompositeViewer::checkEvents() method that checks for available events rather than rely upon the more heavier weight eventTraversals() method. The eventTraversals() method design is focused on being done as part of a full frame and was hacked to work in the case of run or demand but didn't handle me moving the frame() event generation into. There are good reasons to move frame() event, but not so good reasons to do a full event traversal as a means for checking whether a full frame is needed or not. The introduction of the checkEvents() method required quite a few changes in other classes to support it, fingers crossed I haven't broken the build in the process of making these changes, unfortunately I can't test out OSX, iOS, Windows builds so will have rely upon the community to test of these changes that I had to make to the platform specific GraphicsWindow implementations. I have now checked in my changes to svn/trunk, could you test them out and let me know if things are working OK now. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
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 jud...@mfrac.com 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_INFOReset 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 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] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
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 jud...@mfrac.com 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_INFOReset 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
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
Index: osgviewer.cpp
===
--- osgviewer.cpp (revision 45025)
+++ osgviewer.cpp (working copy)
@@ -52,6 +52,68 @@
#define GL_TIMEOUT_IGNORED0xull
#endif
+namespace
+{
+
+/// Modified Viewer implementation to expose the problem I encountered.
+class osg_viewer_t : public osgViewer::Viewer
+{
+public:
+osg_viewer_t ();
+
+osg_viewer_t (osg::ArgumentParser arguments);
+
+/// Copy constructor (not implemented).
+osg_viewer_t (
+ const osgViewer::Viewer viewer, const osg::CopyOp copyop
+);
+
+/* osgViewer::ViewerBase */
+
+virtual bool
+checkNeedToDoFrame ();
+};
+
+} // anonymous namespace
+
+osg_viewer_t::osg_viewer_t ()
+: osgViewer::Viewer ()
+{
+}
+
+osg_viewer_t::osg_viewer_t
Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
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 jud...@mfrac.com 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 jud...@mfrac.com 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_INFOReset 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 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 ___ 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] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
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 jud...@mfrac.com 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 jud...@mfrac.com 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_INFOReset 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 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
Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
HI Judson, I have done a refactor of osgViewer's internally handling of mouse events to allow for seamless handling of distortion correction set ups, there is chance that this might have broken something that I haven't yet observed in my own testing. Other than this there hasn't been any changes that effect culling. Do you see problems with using osgviewer? Robert. On 22 May 2013 14:59, Judson Weissert jud...@mfrac.com wrote: Hello, I have recently upgraded to the 3.1.6 development release of the OSG library (from 3.1.2) and encountered some behavior changes when manipulating a model using the Trackball Manipulator (I did derive from it though and modify some non-mouse related features). Compiled by VS2010, running on Windows 7 64-bit. Basically, when I throw (release mouse while dragging) the view using either the middle mouse button (pan), or the right mouse button (move towards/away), the model disappears from view entirely, and the statistics view shows the triangle count as zero. Statically placed HUD geometry (not usually affected by the manipulator at all) is also culled. I looked through the Changelog and source code changes a bit, but I feel like I am searching for a needle in a haystack. Does anyone know of any changes in the culling logic or Trackball manipulator that might explain this behavior? Thanks, Judson ___ 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] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
Robert, On 5/22/2013 10:23 AM, Robert Osfield wrote: HI Judson, I have done a refactor of osgViewer's internally handling of mouse events to allow for seamless handling of distortion correction set ups, there is chance that this might have broken something that I haven't yet observed in my own testing. Other than this there hasn't been any changes that effect culling. Do you see problems with using osgviewer? The osgviewer application does not seem to exhibit the problem. Also, it does not happen when emulating a throw manipulation on a touch screen (via a rightclick emulation and drag). I switched back to using the standard osgGA::TrackballManipulator, but it did not solve my problem. I will continue searching. Thanks, Judson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
Robert, The viewer I am running has ON_DEMAND frame updates. When I remove the line viewer-setRunFrameScheme (osgViewer::ViewerBase::ON_DEMAND); the disappearing geometry behavior goes away. However, I was not able to replicate the problem by applying ON_DEMAND frame updating to the osgviewer application. Thus, there is still a piece of the puzzle that I am missing. Regards, Judson On 5/22/2013 12:10 PM, Judson Weissert wrote: Robert, On 5/22/2013 10:23 AM, Robert Osfield wrote: HI Judson, I have done a refactor of osgViewer's internally handling of mouse events to allow for seamless handling of distortion correction set ups, there is chance that this might have broken something that I haven't yet observed in my own testing. Other than this there hasn't been any changes that effect culling. Do you see problems with using osgviewer? The osgviewer application does not seem to exhibit the problem. Also, it does not happen when emulating a throw manipulation on a touch screen (via a rightclick emulation and drag). I switched back to using the standard osgGA::TrackballManipulator, but it did not solve my problem. I will continue searching. Thanks, Judson ___ 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] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
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. On 22 May 2013 18:31, Judson Weissert jud...@mfrac.com wrote: Robert, The viewer I am running has ON_DEMAND frame updates. When I remove the line viewer-setRunFrameScheme (osgViewer::ViewerBase::ON_DEMAND); the disappearing geometry behavior goes away. However, I was not able to replicate the problem by applying ON_DEMAND frame updating to the osgviewer application. Thus, there is still a piece of the puzzle that I am missing. Regards, Judson On 5/22/2013 12:10 PM, Judson Weissert wrote: Robert, On 5/22/2013 10:23 AM, Robert Osfield wrote: HI Judson, I have done a refactor of osgViewer's internally handling of mouse events to allow for seamless handling of distortion correction set ups, there is chance that this might have broken something that I haven't yet observed in my own testing. Other than this there hasn't been any changes that effect culling. Do you see problems with using osgviewer? The osgviewer application does not seem to exhibit the problem. Also, it does not happen when emulating a throw manipulation on a touch screen (via a rightclick emulation and drag). I switched back to using the standard osgGA::TrackballManipulator, but it did not solve my problem. I will continue searching. Thanks, Judson ___ 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] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
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_INFOReset 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 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
