First, we can confirm this by adding a few more alignToVec calls (like you did earlier) and see if that makes the problem less likely to occur (that is, it'll hopefully mean the destination needs to be much closer to the opposite pole for the problem to occur).
Actually my first tests (not posted on this thread) had very strange results do to that. I did think of that and modified your function to get instant rotations:
Call "alignToVec(........, 1)" once every frame over several frames to complete the alignment (this will be quite smooth and quite quick), or several times in one frame for a complete alignment in only one frame.
If you would rather deal with the imprecisions yourself, remove the "* vec_length(rotAxis);".
Modified version of your function I am currently using:
function alignToVec(ANGLE* entAng, VECTOR* vec, VECTOR* axis, var factor) {
vec_rotate(axis, entAng);
vec_normalize(axis, 1);
vec_normalize(vec, 1);
VECTOR rotAxis;
vec_cross(rotAxis, vec, axis);
var angle = -acos((float)vec_dot(axis, vec)) * factor; // * vec_length(rotAxis);
ANGLE rotAngle;
ang_for_axis(rotAngle, rotAxis, angle);
ang_add(entAng, rotAngle);
}
Secondly, if the vehicle adjusts its angle gradually rather than instantly (add a max_rotation parameter to the look_at function and make sure the function never rotates the vehicle more than the amount given in this parameter -- make it 5*time_step, for example, and the vehicle won't adjust its pan by more than 5 degrees per tick), its turning circle might let the vehicle get far enough away from its destination's pole that it can escape that "inaccurate zone" and continue to its destination.
Could be a solution but... When reaching the "problematic zones" wouldn't it do a wierd little turn before going back to it's correct path? I would like to avoid that strange behaviour if possible.
Another problem I see with this approach is if the destination is close to the moving vehicle, if it's not far enough for it to fully rotate towards it before reaching the destination, it would result in the vehicle going around it's destination in circles forever.
Thirdly, if the vehicle only checks the angle to its destination once a second or so, it should be able to get far enough away from the pole after the first check that any checks after that will be fairly consistent.
I like this idea more, but it leaves the solution to randomness. If by any chance the delay between checks lands close to the "problematic zone" it could result in the vehicle going back and fourth. I don't feel confortable leaving the solution to a random delay that could potencially land on a problematic zone sometimes.
EDIT:I have done further tests drawning an axsis going through the planet's core aligned to our vehicle's normal (blue line).
http://www.youtube.com/watch?v=a-1EbjmkwMkThis proves the problem is not when going through the same point on the opposite side?
current brain status: even more dazed and extremely confused...
EDIT2:Done further tests, this time debugging V_Path (green line).
V_Path is the temporary path for the pan calculations. It is a rotated version of our destination.
http://www.youtube.com/watch?v=ntPkiiZTV8YAha! Finally found the culprit! It seems the problem occurs when our temporary path is aligned vertically.
(I'm a little less confused now, I understand what is causing this but it seems I can't figure out how to fix it)
I am sorry, I was editing my previous post while you were answering. I wanted to repost this part just in case you missed it. (check the green line in the second video at 1:20 and after)
I think the solution could be to check if V_Path is straight up or down (that seems to be the problem), and if it is aligned vertically then do not rotate the vehicle and let it contiue in a straight line untill the the rotated destination (V_Path) is not vertically aligned anymore. Not sure if that could be the solution, just a random thought...EDIT:Nevermind, I think I understood you wrong before. Is this a gimbal-lock problem where I translate the gimbal lock centered around an arbitrary rotated axsis because I used vec_rotateback()?
If so... Is there any way to overcome this problem removing the "vec_to_angle(V_Ang, V_Path);" in the look_at function? And mabe replacing it using your alignToVec() function to perform the calculation?
