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

Reply via email to