[osg-users] Camera manipulator changes for inverted y axis
Hi, I reverted the y axis by adjusting the camera projection matrix: Code: camera->setProjectionMatrixAsPerspective(30.0f, static_cast(traits->width) / static_cast(traits->height), 1.0f, 1.0f); auto originalProjection = camera->getProjectionMatrix(); osg::Matrixd reverseYMat; reverseYMat.makeScale(osg::Vec3d(1.0, -1.0, 1.0)); camera->setProjectionMatrix(reverseYMat * originalProjection); The code works, however I have a problem with the trackball manipulator. The manipulator sets the home position reverse in Z direction: everything is positioned upside down. Furthermore when I rotate the camera the movement in the Z direction seems to be reversed. What should I do to change the behavior of the manipulator to the expected one? Thank you! Cheers, tunc -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=68828#68828 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator needs to apply projection matrix extents in update traversal
Yes I guess we could do via an EventHandler (which we have done for other things interested in events) except all our various extended 'camera manipulators' are added (i.e. set active) via the View::setCameraManipulator(osgGA::CameraManipulator*) ... so sticking to the pattern this particular specialised manipulator was implemented this way. robertosfield wrote: Hi Nick, You still don't need a CameraManipulator to do this, a custom EventHandler as some code setting the camera would be sufficient. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55281#55281 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator needs to apply projection matrix extents in update traversal
HI Nick,
The svn/trunk and recent dev releases of the OSG have a
CameraManipulator::updateCamera(osg::Camera) method that allows you to set
any properties you want on the View's Camera rather than pulling the view
matrix as was done previously.
The other bit of the jigsaw for you specific implementation requirements
might simply to not use a CameraManipulator at all and just set the view
and projection matrices on each new frame within your own frame loop.
CameraManipulators are only one way to control the view and while often
convinient to use in their default form aren't all required usage.
Robert.
On 17 July 2013 02:56, Nick McEvoy nmc...@gmail.com wrote:
I'm writing a camera manipulator but have an issue where I need the
manipulator to be visited during the update traversal ( after the scene
graph has been updated). Without going into too much detail ... the basic
reason I require this is ... that my manipulator needs to set the
orthographic projection matrix extents based on the updated scene. I really
need to set the orthographic projection matrix extents at about the point
where the camera view matrix is applied (see point 2c below).
So as we all know the viewer performs:
1. event traversal
2. update traversal
3. rendering traversals
And my area of concern is the viewers update traversal (point 2) which
does the following:
2a. visits the scene graph
2b. visits the camera
2c. sets the cameras view matrix (using the camera manipulators inverse
matrix)
BUT it does NOT visit the active manipulator or have any way for the
active manipulator to apply a projection matrix if it so wishes
(specifically at point 2c). :(
I've considered and tested the following, but they all feel like hacks:
- set the orthographic projection matrix extents in
MyCameraManipulator::getInverseMatrix(), called at point 2c. But I think
this is a bad idea because this method is really used for other purposes.
- have my active camera manipulator add an update callback onto the
current camera and so therefore set my projection matrix extents when I'm
visited at point 2b. But then I must also have code to remove the update
callback from the camera when my manipulator is no longer active or
removed. My implementation on this works, but it feels dirty.
Does anyone have a simpler/cleaner solution?
The real question is why is there no mechanism in OSG to allow the camera
manipulator to update the projection matrix at the appropriate time? Maybe
something like the ideas below (++1) or (++2) could be considered?
Code:
void Viewer::updateTraversal()
{
if (_camera.valid() _camera-getUpdateCallback())
_camera-accept(*_updateVisitor);
(++1) if (_cameraManipulator.valid()
_cameraManipulator-getUpdateCallback())
_cameraManipulator-accept(*_updateVisitor);
if (_cameraManipulator.valid())
{
_camera-setViewMatrix(_cameraManipulator-getInverseMatrix());
(++2) _cameraManipulator-updateProjectionMatrix();
}
}
Thoughts?
Cheers,
Nick[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=55232#55232
___
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 needs to apply projection matrix extents in update traversal
Excellent, the new updateCamera() method on the trunk sounds exactly what we need ! :) We are on osg 3.0.1 so for now, so until we update to the latest, I've just put in our work around which connects our active manipulator to the camera's update callback and that seems to work ok. Also just to clarify, we do need a manipulator for our implementation as it is an orthographic camera manipulator that takes user input to rotate, but has an additional feature to auto-fit all objects in the scene by setting the ortho projection extents. Cheers, Nick robertosfield wrote: HI Nick, The svn/trunk and recent dev releases of the OSG have a CameraManipulator::updateCamera(osg::Camera) method that allows you to set any properties you want on the View's Camera rather than pulling the view matrix as was done previously. The other bit of the jigsaw for you specific implementation requirements might simply to not use a CameraManipulator at all and just set the view and projection matrices on each new frame within your own frame loop. CameraManipulators are only one way to control the view and while often convinient to use in their default form aren't all required usage. Robert. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55273#55273 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator needs to apply projection matrix extents in update traversal
Hi Nick, On 19 July 2013 00:08, Nick McEvoy nmc...@gmail.com wrote: Excellent, the new updateCamera() method on the trunk sounds exactly what we need ! :) We are on osg 3.0.1 so for now, so until we update to the latest, I've just put in our work around which connects our active manipulator to the camera's update callback and that seems to work ok. Also just to clarify, we do need a manipulator for our implementation as it is an orthographic camera manipulator that takes user input to rotate, but has an additional feature to auto-fit all objects in the scene by setting the ortho projection extents. You still don't need a CameraManipulator to do this, a custom EventHandler as some code setting the camera would be sufficient. 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 needs to apply projection matrix extents in update traversal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Nick, On 07/17/2013 03:56 AM, Nick McEvoy wrote: I'm writing a camera manipulator but have an issue where I need the manipulator to be visited during the update traversal ( after the scene graph has been updated). Without going into too much detail ... the basic reason I require this is ... that my manipulator needs to set the orthographic projection matrix extents based on the updated scene. I really need to set the orthographic projection matrix extents at about the point where the camera view matrix is applied (see point 2c below). You should intercept the cull visitor, not update one. Cull is what is done right before rendering and after update. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFR5oK9n11XseNj94gRAiM+AJ9OGJxBzijW2YXs550uL3KanKxUPACfYFUF vumSooid17kMBLRpqvjkc/M= =Di6d -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Camera Manipulator needs to apply projection matrix extents in update traversal
I'm writing a camera manipulator but have an issue where I need the manipulator
to be visited during the update traversal ( after the scene graph has been
updated). Without going into too much detail ... the basic reason I require
this is ... that my manipulator needs to set the orthographic projection matrix
extents based on the updated scene. I really need to set the orthographic
projection matrix extents at about the point where the camera view matrix is
applied (see point 2c below).
So as we all know the viewer performs:
1. event traversal
2. update traversal
3. rendering traversals
And my area of concern is the viewers update traversal (point 2) which does the
following:
2a. visits the scene graph
2b. visits the camera
2c. sets the cameras view matrix (using the camera manipulators inverse matrix)
BUT it does NOT visit the active manipulator or have any way for the active
manipulator to apply a projection matrix if it so wishes (specifically at point
2c). :(
I've considered and tested the following, but they all feel like hacks:
- set the orthographic projection matrix extents in
MyCameraManipulator::getInverseMatrix(), called at point 2c. But I think this
is a bad idea because this method is really used for other purposes.
- have my active camera manipulator add an update callback onto the current
camera and so therefore set my projection matrix extents when I'm visited at
point 2b. But then I must also have code to remove the update callback from the
camera when my manipulator is no longer active or removed. My implementation on
this works, but it feels dirty.
Does anyone have a simpler/cleaner solution?
The real question is why is there no mechanism in OSG to allow the camera
manipulator to update the projection matrix at the appropriate time? Maybe
something like the ideas below (++1) or (++2) could be considered?
Code:
void Viewer::updateTraversal()
{
if (_camera.valid() _camera-getUpdateCallback())
_camera-accept(*_updateVisitor);
(++1) if (_cameraManipulator.valid()
_cameraManipulator-getUpdateCallback())
_cameraManipulator-accept(*_updateVisitor);
if (_cameraManipulator.valid())
{
_camera-setViewMatrix(_cameraManipulator-getInverseMatrix());
(++2) _cameraManipulator-updateProjectionMatrix();
}
}
Thoughts?
Cheers,
Nick[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=55232#55232
___
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 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
[osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
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
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
[osg-users] Camera manipulator zoomFactor
Hi, Is there an easy way to invert the wheel zoom factor on TrackballCameraManipulator? I have a feeling that once I've seen a property where you can set this, and if you set it to -1, the zoom scrolling will behave opposite. I have a cameraManipulator derived from TrackballCam..Man.. the second way will be to handle the mouse wheel event, but i hope there is an easier way. I've searched on the forum but didn't find a solution. Thank you! Cheers, Peter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=53187#53187 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera manipulator zoomFactor
I am sorry about the useless topic. I was searching the property on a wrong object manipulator-setWheelZoomFactor() -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=53189#53189 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator problem
Hi Peterakos,
There isn't any way a third party will be able to diagnose the problem
with your code with such a tiny extract of code. The best I can
suggest is develop your own skills of hunting down and fixing bugs.
Using a debug to see the flow of control, or add debug message that
output results to the console so you can learn about what is
happening. With looking things more closely the problem in your code
should jump out.
Robert.
On 19 February 2013 01:32, Peterakos hay...@gmail.com wrote:
Hello.
I try to make my own camera manipulator in which the push events with
X lower than the half of the window will be ignored.
I created a class, which derives trackball manipulator.
Here is the handle method
virtual bool handle( const osgGA::GUIEventAdapter ea,
osgGA::GUIActionAdapter us ) {
if (ea.getEventType() == osgGA::GUIEventAdapter::PUSH
isInBounds(ea.getX(), ea.getY())) {
return true;
}
return osgGA::TrackballManipulator::handle(ea, us);
}
Even though I return true (which means i dont want further handle), it
keeps taking into account the event.
Is there anything wrong with the code above ?
thnx.
___
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] Camera Manipulator problem
Hello.
I try to make my own camera manipulator in which the push events with
X lower than the half of the window will be ignored.
I created a class, which derives trackball manipulator.
Here is the handle method
virtual bool handle( const osgGA::GUIEventAdapter ea,
osgGA::GUIActionAdapter us ) {
if (ea.getEventType() == osgGA::GUIEventAdapter::PUSH
isInBounds(ea.getX(), ea.getY())) {
return true;
}
return osgGA::TrackballManipulator::handle(ea, us);
}
Even though I return true (which means i dont want further handle), it
keeps taking into account the event.
Is there anything wrong with the code above ?
thnx.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera manipulator velocity and home() calculation affected after scaling nodes
You can find it from the settings. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49674#49674 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera manipulator velocity and home() calculation affected after scaling nodes (partially resolved)
On 8/27/2012 3:14 PM, Jeremy Moles wrote:
A Drawable can have a special ComputeBoundsCallback() (something like
that, I'm on my phone right now and can't look it up), so you could use
that as well...
Here is the code I came up with after your suggestion that does resolve
my problem (I attach the callback directly to the PAT in question):
[code]
/// This callback is used to prevent the bounding sphere associated with a
/// osg::PositionAttitudeTransform from modifying the bounding sphere due to
/// its scaling factor.
class keep_bounding_sphere_t : public
osg::Node::ComputeBoundingSphereCallback
{
public:
keep_bounding_sphere_t ();
keep_bounding_sphere_t (const osg::Vec3 axes);
keep_bounding_sphere_t (
const keep_bounding_sphere_t other, const osg::CopyOp copyop
);
META_Object (anonymous, keep_bounding_sphere_t);
/* * * osg::Node * * */
virtual osg::BoundingSphere
computeBound (const osg::Node node) const;
private:
/// The axes that might be scaled and should be checked.
/// e.g. osg::Z_AXIS to check only the z-axis.
osg::Vec3 axes_;
};
keep_bounding_sphere_t::keep_bounding_sphere_t ()
: ComputeBoundingSphereCallback (),
axes_ (1.0f, 1.0f, 1.0f)
{
}
keep_bounding_sphere_t::keep_bounding_sphere_t (const osg::Vec3 axes)
: ComputeBoundingSphereCallback (),
axes_ (axes)
{
}
keep_bounding_sphere_t::keep_bounding_sphere_t (
const keep_bounding_sphere_t other, const osg::CopyOp copyop )
: ComputeBoundingSphereCallback (other, copyop),
axes_ (other.axes_)
{
}
osg::BoundingSphere
keep_bounding_sphere_t::computeBound (const osg::Node node) const
{
osg::BoundingSphere out = node.computeBound ();
const osg::PositionAttitudeTransform *pat =
dynamic_cast const osg::PositionAttitudeTransform * (node);
if (!pat)
return out;
osg::Vec3d scale = pat-getScale ();
double sscale = 1.0;
if (axes_.x ())
sscale = scale.x ();
if (axes_.y () scale.y () sscale)
sscale = scale.y ();
if (axes_.z () scale.z () sscale)
sscale = scale.z ();
if (sscale)
out.set (out.center () , out.radius () / sscale);
return out;
}
[/code]
My understanding of Transform::computeBound() could be better, but in my
case, it was effectively multiplying the bounding sphere radius by the
scaling factor even though the scaling factor only applied to a single
axis and should not have been a factor when calculating the boundary sphere.
Thus, the code above works provided the extent of the geometry along the
axis being scaled will never be larger than the extent of the geometry
along the other axes. I can think of a few improvements to this code
(like compute the bounds of the child node(s) directly then determine
what to do with the scale values). However, does this seem like a
proper/common approach to solving this problem? Another approach might
be to override the PositionAttitudeTransform node directly?
Regards,
Judson
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Camera manipulator velocity and home() calculation affected after scaling nodes
Hello, I was hoping someone could help me with a camera manipulator/scaling problem that I have been having. I have a scene graph that contains geometry representing a hydraulic fracture. The fracture length is of the order 1000ft, the height is of the order 100ft, and the width is of the order .01ft. I am trying to appy a width exaggeration factor to the model in order to artificially inflate the geometry along the width axis (in my case it is along the z-axis). To accomplish this, I call osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on the PAT node that I use to orient the fracture in the model. This works as expected, and the fracture width is exaggerated. However, the camera manipulator (osgGA::TrackballManipulator) does not return to the same home position. The larger the scale value, the further the home position seems to be from the model. Also, the velocity of the camera (model distance / screen pixel distance) when manipulated via the mouse increases with the scale value. That is, dragging the mouse an inch on the screen results in a larger camera manipulation when the scale value is increased. Perhaps I am making some false assumptions regarding how the camera manipulators and scaling operations interact? Is the scaling operation messing up a bounding box calculation somewhere? I tried computing then drawing the bounding box of the root node, but it did not seem to change for either case. That is, the exaggerated fracture width does not make the overall volume of the scene any larger (as far as I can tell). Additional information: Lib Version: OpenSceneGraph 3.1.2 (Compiled with VS2010 on Windows 7 64-bit) Manipulator: osgGA::TrackballManipulator Any hints/tips would be greatly appreciated. Thank you, Judson Weissert ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera manipulator velocity and home() calculation affected after scaling nodes
On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote: Hello, I was hoping someone could help me with a camera manipulator/scaling problem that I have been having. I have a scene graph that contains geometry representing a hydraulic fracture. The fracture length is of the order 1000ft, the height is of the order 100ft, and the width is of the order .01ft. I am trying to appy a width exaggeration factor to the model in order to artificially inflate the geometry along the width axis (in my case it is along the z-axis). To accomplish this, I call osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on the PAT node that I use to orient the fracture in the model. This works as expected, and the fracture width is exaggerated. However, the camera manipulator (osgGA::TrackballManipulator) does not return to the same home position. The larger the scale value, the further the home position seems to be from the model. Also, the velocity of the camera (model distance / screen pixel distance) when manipulated via the mouse increases with the scale value. That is, dragging the mouse an inch on the screen results in a larger camera manipulation when the scale value is increased. Perhaps I am making some false assumptions regarding how the camera manipulators and scaling operations interact? Is the scaling operation messing up a bounding box calculation somewhere? I tried computing then drawing the bounding box of the root node, but it did not seem to change for either case. That is, the exaggerated fracture width does not make the overall volume of the scene any larger (as far as I can tell). I've been working on a custom OrthographicCameraManipulator (and have done FirstPersonShooter and other kinds of CameraManipulators in the past) and I've never seen this behave OTHER than how you're describing. Scaling the PAT will definitely affect the home position of the osgGA::StandardManipulator, so you may end up having to do something like: osgGA::CameraManipulator* cm = viewer.getCameraManipulator(); cm-setHomePosition(...); That should also set autoComputeHomePosition to false, so it'll stick. I could, of course, be misunderstanding the question. :) Additional information: Lib Version: OpenSceneGraph 3.1.2 (Compiled with VS2010 on Windows 7 64-bit) Manipulator: osgGA::TrackballManipulator Any hints/tips would be greatly appreciated. Thank you, Judson Weissert ___ 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 velocity and home() calculation affected after scaling nodes
On Mon, 2012-08-27 at 15:12 -0400, Judson Weissert wrote: On 8/27/2012 2:22 PM, Jeremy Moles wrote: On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote: Hello, I was hoping someone could help me with a camera manipulator/scaling problem that I have been having. I have a scene graph that contains geometry representing a hydraulic fracture. The fracture length is of the order 1000ft, the height is of the order 100ft, and the width is of the order .01ft. I am trying to appy a width exaggeration factor to the model in order to artificially inflate the geometry along the width axis (in my case it is along the z-axis). To accomplish this, I call osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on the PAT node that I use to orient the fracture in the model. This works as expected, and the fracture width is exaggerated. However, the camera manipulator (osgGA::TrackballManipulator) does not return to the same home position. The larger the scale value, the further the home position seems to be from the model. Also, the velocity of the camera (model distance / screen pixel distance) when manipulated via the mouse increases with the scale value. That is, dragging the mouse an inch on the screen results in a larger camera manipulation when the scale value is increased. Perhaps I am making some false assumptions regarding how the camera manipulators and scaling operations interact? Is the scaling operation messing up a bounding box calculation somewhere? I tried computing then drawing the bounding box of the root node, but it did not seem to change for either case. That is, the exaggerated fracture width does not make the overall volume of the scene any larger (as far as I can tell). I've been working on a custom OrthographicCameraManipulator (and have done FirstPersonShooter and other kinds of CameraManipulators in the past) and I've never seen this behave OTHER than how you're describing. Scaling the PAT will definitely affect the home position of the osgGA::StandardManipulator, so you may end up having to do something like: osgGA::CameraManipulator* cm = viewer.getCameraManipulator(); cm-setHomePosition(...); That should also set autoComputeHomePosition to false, so it'll stick. I could, of course, be misunderstanding the question. :) Thank you. After thinking about what you said, I figured I would revisit my bounding box code. I must have made a mistake the first time around because this time I do get a completely different bounding box for the scene when the scale changes. Therefore, the code that is computing the home position thinks that it needs to view a huge volume, even though most of that volume does not actually contain any drawables. Therefore, I think I need to fix the bounds calculation and then I will still be able to rely on the default ComputeHomePosition algorithm. So far I have just relied on the default bounds() calculations. Thanks, A Drawable can have a special ComputeBoundsCallback() (something like that, I'm on my phone right now and can't look it up), so you could use that as well... 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 velocity and home() calculation affected after scaling nodes
On 8/27/2012 2:22 PM, Jeremy Moles wrote: On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote: Hello, I was hoping someone could help me with a camera manipulator/scaling problem that I have been having. I have a scene graph that contains geometry representing a hydraulic fracture. The fracture length is of the order 1000ft, the height is of the order 100ft, and the width is of the order .01ft. I am trying to appy a width exaggeration factor to the model in order to artificially inflate the geometry along the width axis (in my case it is along the z-axis). To accomplish this, I call osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on the PAT node that I use to orient the fracture in the model. This works as expected, and the fracture width is exaggerated. However, the camera manipulator (osgGA::TrackballManipulator) does not return to the same home position. The larger the scale value, the further the home position seems to be from the model. Also, the velocity of the camera (model distance / screen pixel distance) when manipulated via the mouse increases with the scale value. That is, dragging the mouse an inch on the screen results in a larger camera manipulation when the scale value is increased. Perhaps I am making some false assumptions regarding how the camera manipulators and scaling operations interact? Is the scaling operation messing up a bounding box calculation somewhere? I tried computing then drawing the bounding box of the root node, but it did not seem to change for either case. That is, the exaggerated fracture width does not make the overall volume of the scene any larger (as far as I can tell). I've been working on a custom OrthographicCameraManipulator (and have done FirstPersonShooter and other kinds of CameraManipulators in the past) and I've never seen this behave OTHER than how you're describing. Scaling the PAT will definitely affect the home position of the osgGA::StandardManipulator, so you may end up having to do something like: osgGA::CameraManipulator* cm = viewer.getCameraManipulator(); cm-setHomePosition(...); That should also set autoComputeHomePosition to false, so it'll stick. I could, of course, be misunderstanding the question. :) Thank you. After thinking about what you said, I figured I would revisit my bounding box code. I must have made a mistake the first time around because this time I do get a completely different bounding box for the scene when the scale changes. Therefore, the code that is computing the home position thinks that it needs to view a huge volume, even though most of that volume does not actually contain any drawables. Therefore, I think I need to fix the bounds calculation and then I will still be able to rely on the default ComputeHomePosition algorithm. So far I have just relied on the default bounds() calculations. 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 proposal
Hi Robert, I agree that the Camera as an argument makes more sense. Thanks for merging the submission. Cheers, Ricky On Mon, Jul 9, 2012 at 7:38 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Riccardo, On review of the submission I've decided that passing in a Camera rather than a pointer would make it clear that a valid Camera object should be passed in rather than a pointer which could be NULL or pointing to a valid Camera object. This brings the method more into line with how this type of method is invoked elsewhere in the OSG. 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 proposal
Hi Riccardo, Sorry for the very long delay in getting to review your suggested changes, I've now done the review and the changes look good, the only amendment I made to rename the parameter name Camera* pCamera to Camera* camera as from the context it's obvious that camera is a Camera* one doesn't need to add extra short hand in the name to make this clear, rather the extra p just makes the code less human readable. Changes now merged and submitted to svn/trunk. 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 proposal
Hi Riccardo, On review of the submission I've decided that passing in a Camera rather than a pointer would make it clear that a valid Camera object should be passed in rather than a pointer which could be NULL or pointing to a valid Camera object. This brings the method more into line with how this type of method is invoked elsewhere in the OSG. 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 proposal
Hi Robert and All, I just wanted to know if the proposal I made some weeks ago doesn't seem to fit some requirements, or simply passed unnoticed. Thank you, Ricky On Wed, Mar 14, 2012 at 15:42, Riccardo Corsi riccardo.co...@kairos3d.itwrote: Hi all, sorry that it took long to setup the proposal... Eventually the code change was minimal: 1. added a method void updateCamera(osg::Camera*) on CameraManip base class. I propose a default implementation that sets the camera view matrix by using the existing getInverseMatrix method, so that standard manipulators don't need any change. 2. viewer classes call the new method instead of setting explicitly the camera view matrix, for instance: //old call -_camera-setViewMatrix(_cameraManipulator-getInverseMatrix()); _cameraManipulator-updateCamera(_camera); This brings enough flexibility for the cases that I have in mind at the moment. The changed files are in the attached zip, based on osg 3.1.0. If it's better not to provide a default implementation for the new method, I can remove it and re-implement it in all derived manipulators. If the approach looks reasonable I will make a submission out of it. Ricky On Tue, Mar 6, 2012 at 17:06, Robert Osfield robert.osfi...@gmail.comwrote: HI Ricky, On 6 March 2012 14:36, Riccardo Corsi riccardo.co...@kairos3d.it wrote: I totally agree on the general approach. Still, if you want to go for the change on the osgGA::CameraManipulator base class as a first step, I'd be glad to help with that. Why not have a bash at modifying osgGA::CameraManipulator to work for the purpose you have in mind then post this as proposal, we can then tweak this if required. 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 proposal
Hi Riccardo, On 5 April 2012 11:37, Riccardo Corsi riccardo.co...@kairos3d.it wrote: I just wanted to know if the proposal I made some weeks ago doesn't seem to fit some requirements, or simply passed unnoticed. I'm afraid I haven't had a chance to review it yet. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Camera Manipulator?
Hello -
I am attempting to use the output from an attitude heading reference
system to orient the Camera over some terrain which I created using the
National Elevation Dataset and VirtualPlanetBuilder. When I view the
terrain database using osgviewer, I see everything as I expect.
However.. when I take out the pre-built camera manipulators, I end up
not being able to see any terrain at all. I get a blank blue screen (or,
more recently, a blank black screen).
Rather than calling viewer.run(), I'm doing:
while (!viewer.done() sensorHasData) {
cameraRotation.makeRotate(
osg::DegreesToRadians(euler_data.m_roll),
osg::Vec3(0,1,0), // roll
osg::DegreesToRadians(euler_data.m_pitch),
osg::Vec3(1,0,0) , // pitch
osg::DegreesToRadians(euler_data.m_yaw),
osg::Vec3(0,0,1) ); // heading
myCameraMatrix = (cameraOffsetRotation * cameraRotation) *
cameraTrans;
osg::Matrixd i = myCameraMatrix.inverse(myCameraMatrix);
viewer.getCamera()-setViewMatrix(( osg::Matrixd(i.ptr() )) *
osg::Matrixd::rotate( -M_PI/2.0, 1, 0, 0 ) );
viewer.frame();
}
It seems like setting a manipulator is required, but from research it
seems like I should be able to manipulate the camera's view inside the
while loop as well.
I must be missing something. I've been working my way through the OSG
3.0 Beginners Guide, but I'm just stuck in this rut.
What could I be doing wrong?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] camera manipulator proposal
Hi Riccardo, The current osgGA::CameraManipulator's are a bit of mess, the way they just control the view matrix is one of their flaws. I merged a set of sweeping changes from Jan Perciva back in May 2010 that added a new inheritance hierarchy and more features, but in hindsight I feels these have just made them more convoluted in design and implementation. Rather than tweak the current CameraManilulator API I feel that a wholesale review of osgGA and the CameraManipulator is long overdue. We have new devices such as multi-touch and MS's Kinect, as well as old ones like joysticks that are really not served properly by osgGA. We really should try and tie these all together. Perhaps this should be an objective for 3.4. In terms of osgGA::CameraManipulator base class I'd like to distil it down to it's core functionality - allowing a manipulator to control a Camera. Potentially we could introduce this change prior to the wholesale revamp. Robert. On 5 March 2012 17:35, Riccardo Corsi riccardo.co...@kairos3d.it wrote: Hi Robert and All, in more than one occasion I've noticed that having access to the camera manipulator in use is not enough to have full control over the camera motion handling. An example is if you want to temporary disable the manip to set the camera position explicitly (in this case you need to remove the manipulator from the viewer, not to get the position overwritten), or if you want to write a manip for an ortho camera, in which case you need access to the camera's projection matrix as well. At the same time we need to preserve the loose coupling between the camera and its manipulator. I think that a possible approach would be a virtual method in the base camera manip like: virtual void osgGA::CameraManipulator::UpdateCamera(osg::Camera* pCam) to be invoked by the viewer classes. Instead of asking the ViewMatrix to the manipulators, they would call this method passing the reference camera and leaving the matrix assignments to the implementation. Do you think it's a reasonable approach? The porting of the existing manipulators to the new interface would be an easy task. Please give me some feedback, if you like the approach I can submit a patch. Thanks, Ricky ___ 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 proposal
Hi Robert, I totally agree on the general approach. Still, if you want to go for the change on the osgGA::CameraManipulator base class as a first step, I'd be glad to help with that. Ricky On Tue, Mar 6, 2012 at 11:44, Robert Osfield robert.osfi...@gmail.comwrote: Hi Riccardo, The current osgGA::CameraManipulator's are a bit of mess, the way they just control the view matrix is one of their flaws. I merged a set of sweeping changes from Jan Perciva back in May 2010 that added a new inheritance hierarchy and more features, but in hindsight I feels these have just made them more convoluted in design and implementation. Rather than tweak the current CameraManilulator API I feel that a wholesale review of osgGA and the CameraManipulator is long overdue. We have new devices such as multi-touch and MS's Kinect, as well as old ones like joysticks that are really not served properly by osgGA. We really should try and tie these all together. Perhaps this should be an objective for 3.4. In terms of osgGA::CameraManipulator base class I'd like to distil it down to it's core functionality - allowing a manipulator to control a Camera. Potentially we could introduce this change prior to the wholesale revamp. Robert. On 5 March 2012 17:35, Riccardo Corsi riccardo.co...@kairos3d.it wrote: Hi Robert and All, in more than one occasion I've noticed that having access to the camera manipulator in use is not enough to have full control over the camera motion handling. An example is if you want to temporary disable the manip to set the camera position explicitly (in this case you need to remove the manipulator from the viewer, not to get the position overwritten), or if you want to write a manip for an ortho camera, in which case you need access to the camera's projection matrix as well. At the same time we need to preserve the loose coupling between the camera and its manipulator. I think that a possible approach would be a virtual method in the base camera manip like: virtual void osgGA::CameraManipulator::UpdateCamera(osg::Camera* pCam) to be invoked by the viewer classes. Instead of asking the ViewMatrix to the manipulators, they would call this method passing the reference camera and leaving the matrix assignments to the implementation. Do you think it's a reasonable approach? The porting of the existing manipulators to the new interface would be an easy task. Please give me some feedback, if you like the approach I can submit a patch. Thanks, Ricky ___ 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 proposal
HI Ricky, On 6 March 2012 14:36, Riccardo Corsi riccardo.co...@kairos3d.it wrote: I totally agree on the general approach. Still, if you want to go for the change on the osgGA::CameraManipulator base class as a first step, I'd be glad to help with that. Why not have a bash at modifying osgGA::CameraManipulator to work for the purpose you have in mind then post this as proposal, we can then tweak this if required. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] camera manipulator proposal
Hi Robert and All, in more than one occasion I've noticed that having access to the camera manipulator in use is not enough to have full control over the camera motion handling. An example is if you want to temporary disable the manip to set the camera position explicitly (in this case you need to remove the manipulator from the viewer, not to get the position overwritten), or if you want to write a manip for an ortho camera, in which case you need access to the camera's projection matrix as well. At the same time we need to preserve the loose coupling between the camera and its manipulator. I think that a possible approach would be a virtual method in the base camera manip like: virtual void osgGA::CameraManipulator::UpdateCamera(osg::Camera* pCam) to be invoked by the viewer classes. Instead of asking the ViewMatrix to the manipulators, they would call this method passing the reference camera and leaving the matrix assignments to the implementation. Do you think it's a reasonable approach? The porting of the existing manipulators to the new interface would be an easy task. Please give me some feedback, if you like the approach I can submit a patch. Thanks, Ricky ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator initial camera pos/orientation
Ted Morris writes: Hi, I need to set an initial viewpoint of my camera manipulators with respect to the local coordinate system of the object. What is the best way to go about that? Hi Ted, I think that osg::Node::getWorldMatrices and osgGA::MatrixManipulator::setHomePosition can help you to do what you are looking for. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Camera Manipulator initial camera pos/orientation
Hi, I need to set an initial viewpoint of my camera manipulators with respect to the local coordinate system of the object. What is the best way to go about that? Thanks! T -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26694#26694 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Camera Manipulator
Greetings,
I'm running into a little snag here.
I utilized the CameraNodeFollower Camera Manipulator as presented in the
NPS tutorial. For all who don't know it basically attaches a node with a
NodeCallback that
obtains the current NodePath of the parent, and multiplies its own offset
from the
parent which is then 'followed'. e.g., :
struct updateAccumulatedMatrix : public osg::NodeCallback
{
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
matrix = osg::computeWorldToLocal(nv-getNodePath() );
traverse(node,nv);
}
osg::Matrix matrix;
};
OK. What is happening is rather strange. It is attached to a MatrixTransform
object.
When the MatrixTransform is updated with an UpdateCallback,
the underlying object jitters every 1/2 to every 1 second (variable).
It is as if the updating of the object in 'out of synch' with the
CameraNodeFollower
CameraManipulator
When I just attached a built-in CameraManipulator, for example a
sgGA::TrackballManipulator,
I don't have the problem. So, it must something with how I am implementing
this NodeFollowerManipulator.
I tried setDataVariance to DYNAMIC on both the MatrixTransform node (parent)
and
the child node with the UpdateCallback attached as above, and that didn't do
anything.
I also played with:
viewer-setThreadingModel(osgViewer::Viewer::SingleThreaded); no change.
Any ideas how to fix this or what might be happening here?
thanks,
Ted
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Camera Manipulator problem
Greetings all,
I'm using the CameraManipulator from the NPS 11.x tutorial to follow a
MatrixTransform
object. The MatrixTransform position/orientation per usual with an Node
UpdateCallback.
The manipulator simply attaches a node to the MatrixTransform node
with a callback which grabs the parent NodePath (of the MatrixTransform
node),
represented in WOrld coordinates; i.e., per the demo code:.
snip
struct updateAccumulatedMatrix : public osg::NodeCallback
{
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
matrix = osg::computeWorldToLocal(nv-getNodePath() );
traverse(node,nv);
}
osg::Matrix matrix;
};
snip
What happens is that the camera appears to occasionally be updated with the
previous frame's
parent object position/orientation. The affect is that it will 'jitter' say,
every 10 frames or something like that...
I tried to setDataVariance(osg::Object::Dynamic) for both the
MatrixTransform and the node and
still the same problem. But, when I attach a built in CameraManipulator to
the viewer I don't have the
problem.
It is as if the node with the Callback is being called sometimes before,
or sometimes after, the MatrixTransform parent object's callback. Possible?
What might I be missing? Is there a way to control when the
CameraManipulator is updating
the view matrix?
the app is running under WinXP 32b through wxWIndows/Visual Studio9, if that
matters.
thanks very much for any insights, suggestions, help--
t
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator
Hola, Let me ask it another way. I'm in a fragment shader. I have the vec4 gl_FragCoord. I do: Code: vec3 windowcoord = vec3(gl_FragCoord.xy, 1.0); vec3 clipcoord = viewportMatrixInverse * windowcoord; vec4 eyecoord = gl_ProjectionMatrixInverse * vec4(clipcoord, 1.0); eyecoord = eyecoord / eyecoord.w; eyecoord.xyz = eyecoord.xyz * (gl_FragCoord.z / eyecoord.z); vec4 worldspace = gl_ModelViewMatrixInverse * eyecoord; worldspace = worldspace / worldspace.w; gl_FragColor = vec4(worldspace.x, worldspace.y, worldspace.z, 1.0); i.e. I try to retrieve the worldspace coordinates of the fragment and I map its color on these coordinates. The viewportMatrixInverse is built as the inverse of the classical viewport transformation ( here (http://old.uvr.gist.ac.kr/wlee/web/techReports/ar/Camera%20Models.html?bcsi-ac-BD206F1A835A2F32=18BDC07B02031eDZGe6ZXsApRSxuIFLPU3rflUQUCwAAAwIAAAOrDQEQDgAANwAAAN/PCQA=)). I still use this ref_ptr osgGA::MatrixManipulator cammanipulator = new osgGA::TrackballManipulator(); What happens is when I move the object/camera, the colors change for any given point of the model (which shouldn't). I tried the same using viewer.getCamera()-getInverseViewMatrix() for the model view and the same for the projection matrix. I even tried with cammanipulator-getMatrix() to get the inversed modelview. I always had that changing colors problem. Thus my questions are: 1) Are the gl_ModelViewMatrix and gl_ProjectionMatrix usables and updated or not? (Is the viewer linked to the OpenGL modelview?) 2) Do we move the viewer or the scene ? Thank you! Cheers, Maxime -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14756#14756 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Camera Manipulator
Hi, Really quick question. In a shader I get back a gl_FragCoord. I use it to try getting back in world space. I did it several ways and I really have the impression that piece of code: Code: ref_ptr osgGA::MatrixManipulator cammanipulator = new osgGA::TrackballManipulator(); viewer.setCameraManipulator(cammanipulator.get()); doesn't move the camera BUT the object. Am I wrong? If not, is there a way to do it? Thank you a lot! Cheers, Max -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14706#14706 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Camera Manipulator
Hello forum, I am going through the example osgimpostor to get the idea of how the quaternion camera is implemented there. The camera manipulator has been derived from the MatrixManipulator class and one of the function that has been over-ridden is setNode(); I would like to find out when that particular function is called and who is calling that. I am definite that it is called, but could not find out who is calling that(some function in another class probably ). Any hint to find that out? Regards Sajjad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator
Hi, Sajjad El Martes 07 Abril 2009ES 10:57:01 ami guru escribió: Hello forum, I am going through the example osgimpostor to get the idea of how the quaternion camera is implemented there. The camera manipulator has been derived from the MatrixManipulator class and one of the function that has been over-ridden is setNode(); I would like to find out when that particular function is called and who is calling that. I am definite that it is called, but could not find out who is calling that(some function in another class probably ). Any hint to find that out? Yes. You must run the program in the debugger, then set a breakpoint on that overriden setNode(). When the debugger stops, you can inspect the calling stack to see which function called that. Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator
Hello Sajjad, I would like to find out when that particular function is called and who is calling that. I am definite that it is called, but could not find out who is calling that(some function in another class probably ). Basic debugging technique: Run the code in the debugger, put a breakpoint in the method and when the breakpoint is hit, check the call stack. Couldn't be simpler :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
