Rotate vector to match another vector-- interpolation issues

[Justin K]

Hey all,

Simple scene here.  

I have a point (pt1)  orbiting another point (pt2). 

pt 1 is located at the origin.

 

pt2 is being animated using the following vex code 

@P.x = cos(ch('frame')*ch('freq'))*ch('amp');
@P.z = sin(ch('frame')*ch('freq'))*ch('amp');
@N = normalize(@P);
@up = {0,1,0};

basically circular pattern animating ove time

Its vector N is always facing the origin--which is the location of pt1.  

 

Pt1 is at the origin {0,0,0}.  It has a starting vector of N = {0,0,1).   And an up vector of {0,1,0};

 

 

I am trying to rotate the N vector of the origin point (pt1) to match the N of the animating point (pt2).  

 

In a wrangle running over pt 1 and atttached to pt 2 I am using the following code

 

vector N2 = point(1,"N",0);
@angle = acos(dot(N2,@N));
@angle_deg = degrees(@angle);
@N = qrotate(quaternion(@angle,@up),@N);

 

This is just the dot product formula being used to derive the angle between the two vectors, and then I am rotating pt1 by that angle.  

The problem is-- the dot product formula is always returning an angle between 0 and 180- not 0 and 360 ,and so I am getting a ping pong effect when it comes to matching the vectors.  This result makes sense mathematically, but is unfortunately not what I want.

 

What is atypically done mathematically to prevent this from happening?    Ideally I'd like to avoid using conditions if there is a more efficient way

 

https://stackoverflow.com/questions/2886606/flipping-issue-when-interpolating-rotations-using-quaternions

The person in this thread seems to be dealing with a similar issue, and as far as I can tell, a potential solution would involved converting the vectors to quaternions then using slerping behavior, but I dont know much about this.

 

 

Any tips would be appreciated.  

Thanks for the help in advance!

 

rotation_issues.hipnc

[toadstorm]

Slerp is also always going to find the shortest interpolation between two quaternions, so unfortunately you'd get a similar effect when trying to interpolate between angles past 180 degrees. You'd have to either find a different way to store your rotation information (e.g. radians around an axis) and use that to figure out your second normal, or you'd have to get a solver involved that computed the difference between the vectors (using arc cosine of the dot product of the two vectors, or maybe using the dihedral VEX function) and figured out the second normal per-timestep.

[PepperRules34]

Well, by mathematical definition the arccosine function will always fetch a result between 0 and 180..

But in order to achieve what you want, why not simply assign v@N the inverse normalized value of (posPt1 - posPt2) calculated at each frame? We are technically not rotating an initial v@N value but creating one every time pt2 moves! Is that something that might work? 

vector posPt2 = point(1,"P",0);

vector normal = normalize(posPt2-@P) * -1;

v@N = normal;

 

rotation_issues_v002.hipnc

[anim]

well, if you are just matching normals why not doing 

@N = v@opinput1_N;