One should avoid using angles in software whenever possible. Use vectors whenever possible.
In 3d I'm finding quternions to be sometimes better than vectors, but the learning curve has taken much longer.
In 3d I'm finding quternions to be sometimes better than vectors, but the learning curve has taken much longer.
Quaternions are popular because they are usually the fastest technique but are notoriously non-intuitive. This is the best guide I have found explaining them in a practical way: https://danceswithcode.net/engineeringnotes/quaternions/quat...
I used that guide to write quaternion functions for one of my projects. It is three times faster than the (also gimbal safe) trigonometric method I used previously. The quaterion functions can be found at the top of: https://github.com/kevinloch/bsrender/blob/main/src/process-.... The rotation quaternion is constructed at the bottom of https://github.com/kevinloch/bsrender/blob/main/src/init-sta.... The vector quaternion is constructed by simply copying the Euclidian x,y,z into i,j,k while setting r=0, and the output x,y,z is copied from i,j,k after rotation.
Beware my program uses a non-standard coordinate system where +y is to the left, being derived from equatorial coordinates used in astronomy where the x->y angle (Right Ascension) increases to the East. Removing the y-axis inversion/reversion steps in the quaternion functions should make them work with conventional coordinates.
The speed advantage of quaternions depends on the use case. If the points being rotated are natively Euclidian and you are performing the same rotation on a billion points then it's a clear winner as the expensive trig functions are only done once while the actual rotation steps are all + and *.
Cartesian <--> polar coordinate transformations applied to the real world must be done carefully because of the magnified error potential at boundary conditions. Again, heavy mathematics as a foundation are necessary to avoid major harm. Honestly, I don't think anyone except Professional Engineers should be allowed to work on critical flight control software. Boeing has been farming out software development to overseas contractors because they're cheaper ($9/hr), not because they're better.
Many formulas can be reduced to operations on dy/dx but you still have to watch of a zero denominator (when used as a slope). You're right as this is certainly common in 2D games but to some degree, it was originally for performance reasons since you don't want to perform a bunch of trig operations when trying to obtain a reasonable refresh rate.