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
