Ok, I've been working on a completely custom utility function for facing one entity to another (for auto-targeting, facing the camera to an object, etc.). This function uses none of the pre-defined 3DGS functions (maybe save for atan()), and I've pretty much got the math figured out, but with one snag. If the pan angle hits 0, the angles reverse themselves. Here's the function's code:



I have another one of these of the same name (overloaded) that directly faces an entity to another by manipulating it's pan and tilt members, but I'm using this one because it's for a bone angle (using it for turning a gun turret towards an aiming reticule).

I've tried many ideas, like using an if condition to switch the angle to it's proper value when it hits 0 (or in this case, 270, since I've subtracted 90 from the initial calculated angle), and using abs() and using an if to reverse, or make negative, the value it returns when it hits the proverbial 0. All of these ideas have done me no good. Maybe it has something to do with converting from radians? Maybe because of the nature of the atan() function? I don't know. All I know right now is that I'm stumped.

Angles can be pretty tricky...thats why as much as possible I use LC functions.
I would definetly use "vec_to_angle" instead of a custom function here

these risk dividing by zero. don't allow that possibility.

the other issue (i'm guessing) is that atan will only get you +- 90 degrees (i know, it uses radians, but you know what i mean). you actually want +- 180 degrees.

ages and ages ago i asked for an atan2 function that takes two parameters (instead of doing atan(disty/distx) you'd do atan2(disty,distx)) and it does the divide safely for you, as well as determining the angle between +- 180 instead of +- 90 degrees (actually in radians). i think they implemented it. i never got around to using it, but here's the one i wrote when i was experimenting with quaternions (uses degrees):
i'm surprised i wasn't using floats. i suggest if you use this function you adapt it to use floats for better precision (very important for many angle applications). hopefully that'll cause no dramas. look up atan2 in the manual if you want to use lite-C's one.

julz

Thx man! I used the LC atan2 function and everything works fine now. What was the problem? Was it dividing by 0 when it reversed the angles?

i'd love to draw it here but i can't... the divide by zero was a potential issue if there ever was a divide by zero but i think that would just crash.

the actual problem was inherent in atan:

imagine dividing 360 degress into four quadrants. in the first and third quadrant tan a (where 'a' is an angle) is positive, and in the second and fourth quadrants tan a is negative. the trouble is, there exists tan b where b is in the third quadrant that is equal to tan a where a is in the first quadrant (and same deal for second and fourth quadrants). so when you do atan x, there are always two possible angles it can be. the atan function resolves this by dealing only in two quadrants, so +-90 degrees. atan2 still deals with one number (x/y) but based on the signs of x and y it can figure out which quadrant the angle is in out of all four quadrants, giving you +-180 degree range.

so basically your code would work fine for perhaps half the angles, and then do the exact opposite for the others until you changed to atan2.

i hope that makes sense

julz