Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

117 Neutral

About uglycoyote

  • Rank
  1. If you are not using Ray casting then is sounds like you are planning to translate, rotate, or scale by some amount that is proportional to the screen space distance that the user drags? This can work okay but you may find it is not ideal. For example, if the user is dragging a distant object then it should ideally move a long distance for a smaller screen space translation, whereas with a nearby object the same screen space movement should move it less far in world space. Getting things to be perspective-correct in this way becomes more crucial if you want to implement something like snap-to-vertex. In that case you really want the point on the 3d object which you initially clicked on to remain under the mouse cursor as you are dragging, which I don't think there is any way to do properly without Ray casting. For rotating the perspective issue is not that important though I don't think, so the main question is just whether to rotate clockwise or counterclockwise around the axis you have selected. I don't have the exact algorithm in my head but I think the intuitive way to do this is that you imagine the user is interacting with the nearer side of the circle of the selected axis. If you project the rotation axis into a 2d screen space vector and then cross product with the drag vector, the sign of the z component will tell you which direction to rotate. For example, if the projected axis is pointing in positive y in screen space and you drag right then you would be grabbing the close side of the circle and spinning counterclockwise. In the case where the axis points directly towards or away from the camera, treat it more like a 2d rotation and cross the drag vector with the vector between the pivot and the mouse then look at the sign of the z component to figure out what whether it is clockwise or counterclockwise.
  2. uglycoyote

    slerp of two pairs of vectors

    I tend to think of SLERP as a rotation about a fixed axis of rotation, where the angle is linearly interpolated between 0 and the final angle.   It's not clear to me what you mean by the "same factor value", but I assume you mean that the angle between A and C is the same as the angle between B and D.   Without getting in to a mathematical proof, I would say that A and B only stay orthogonal if both of their SLERP's use the same axis of rotation.  I'm just coming to this conclusion by example.    e.g., Example 1 -- all vectors in the same plane, A=(0,1,0), B=(1,0,0), C=(0,-1,0), D=(-1,0,0).  Both A and B go through a 180 degree rotation.  Since SLERP rotates them both at the same rate, at t=0.5 the will both be 90 degrees from where they started, and still be orthogonal.   Example 2 -- drastically different axes of rotation:  A=(0,1,0), B=(1,0,0), C=(1,0,0), D=(0,0,1).  In this case, A is rotating around the Z axis by 90 degrees and B is rotating around the Y axis by 90 degrees.  Without taking the time to prove this mathematically, you can do a finger-proof to demonstrate that you can't keep the vectors orthogonal while they are SLERPING.  just try to hold you thumb and forefinger stiffly at 90 degree angles (assume that the vectors remain orthogonal through the rotation), and you will see that as you SLERP vector A towards C, vector B cannot take the shortest path towards D.   Since SLERP takes the shortest path, this is a proof by contradiction.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!