Hi Chuck, I'm afraid as I'm not the original author of this bit of code I can't provide insight above what you can by reading the code.
Robert. On 17 February 2012 17:47, Chuck Seberino <seber...@energid.org> wrote: > Robert et al, > > I have been looking at an problem I have been having with the > osgManipulator::RotateCylinderDragger. I have been trying to follow the code > and there are a few things that stand out as questionable. Here are two > issues I found with osgManipulator/src/Projector.cpp: > > 1. line 202,203 - Here it is trying to find a plane perpendicular to the > eyeVector by taking the cross product of the cylinder axis. It doesn't > correctly handle the case where the local eyeDir is parallel with axisDir. > 2. line 601-606 - The computed plane intersection being calculated in 592 is > being done at the edge of cylinder and the distance will always be >= the > radius and therefore this code will never be hit. Likewise there is an > additional check against hitCylinder here that will never be taken due to the > 'if' clause on line 589. > > The behavior I am seeing is that a small change in mouse drag will cause a > large rotation and in certain cases will also cause a rotation in the > opposite direction. I haven't yet been able to determine the exact cause, > but there were just some things that stuck out as odd. I am almost at the > point where I am going to try replacing all of the line-cylinder intersection > code with my own since it is difficult to understand/verify the algorithm. > > My tests have been performed on trunk using the osgmanipulator example. I > have been testing both with just a RotateCylinderDragger as well as a > TrackballDragger. In the case of the TrackballDragger I removed the > RotateSphereDragger (_xyzDragger) to isolate the picking to just the > RotateCylinderDragger(s). The specific case is trying to pick when the > eyeVector is close to parallel with the major axis of the cylinder (cylinder > looks like a circle). I think issue #1 is somewhat of a red herring, in that > it *should* properly calculate the plane when not exactly parallel, but even > in this case there is still the abnormal behavior. My findings for #2 make > me question the roots of this intersection code and I wanted to get some > feedback on it. > > Thanks in advance. > > Chuck Seberino > _______________________________________________ > 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