Re: [osg-users] Orbit manipulator right and middle mouse movement speed
Hi J-S, Thank you very much for the reply! I've reworked old manipulators so they fit with the new implementation and hierarchy in osgGA. Currently I've created sub classes based on current manipulators in osgGA such as OrbitManipulator however I think it would be great to submit small patched to osg later. I've seen something interesting in the code related to NodeTrackerManipulator and wonder about it, maybe you could shed me some light about it. I saw that if the node mask of the track node is 0x0 we were setting it so that the node is still being updated. Do you remember what kind of problems were related to this, it seems this never got into the osg svn. Thank you! Cheers, Janna -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50935#50935 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Orbit manipulator right and middle mouse movement speed
Hello Janna, Currently I've created sub classes based on current manipulators in osgGA such as OrbitManipulator however I think it would be great to submit small patched to osg later. I think that's generally a good idea as it means you have less code to maintain on your side in the future, and others may benefit from your changes as well. I've seen something interesting in the code related to NodeTrackerManipulator [...] This is something related to the Vortex integration of OSG, so I think we should take this off-list. Not that it's necessarily sensitive information, it's just not useful to others on this list. J-S -- __ Jean-Sebastien Guay jean_...@videotron.ca http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Orbit manipulator right and middle mouse movement speed
Hi, I've noticed that osgGA::OrbitManipulator code for right and middle mouse movement has hard-coded values such as: Code: // doc in parent bool OrbitManipulator::performMovementMiddleMouseButton( const double eventTimeDelta, const double dx, const double dy ) { // pan model float scale = -0.3f * _distance * getThrowScale( eventTimeDelta ); panModel( dx*scale, dy*scale ); return true; } see zoomModel() and performMovementRightMouseButton() for the rest. Is there particular reason scale is hard-coded and no parameter is exposed to be able to modify movement scale for middle and right mouse button? Or is there some other way to do it? Thank you! Janna -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50766#50766 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Orbit manipulator right and middle mouse movement speed
Hello Janna, Is there particular reason scale is hard-coded and no parameter is exposed to be able to modify movement scale for middle and right mouse button? Or is there some other way to do it? There was a large refactoring of camera manipulators about 2 years ago. OrbitManipulator is one of the camera manipulators that were added during that process, so it's relatively recent in OSG. As such, I suspect the reason is simply the standard open-source development one: no one in the past has yet needed to change these values, so they were not exposed. There are two options worth considering IMHO: - The methods are virtual, you can subclass OrbitManipulator and do what you want, even add tweakable parameters with setters/getters and use them in the overridden version of the methods. - Modify the OSG sources to expose new parameters, submit the change and use that once it's integrated. There are a few cases when I was at CM-Labs where I did both: I subclassed to get the behavior I wanted right away (and test that it really worked in our applications) while at the same time submitting a code change to OSG to do the same thing. Once the change was integrated into OSG and we had moved to this new version that included it, I could remove the subclassed version in our code to avoid having to maintain that code in our own code-base. There were more than a few cases where subsequent discussion on this list led to me refactoring or improving my change beyond what I would have done if it had stayed in our code. This kind of collaboration really benefits everyone. Hope this helps, J-S -- __ Jean-Sebastien Guay jean_...@videotron.ca http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org