Software engineers seem to have a lot of problems with trigonometry and especially spherical coordinates/rotations. One recent example is MS FS2020 which despite being a clean-sheet redesign is still unable to render correctly or fly near the poles.

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 *.

Quaternions are "non-intuitive" for people without a math background. If you're a professional software engineer, you should have a CS degree which includes a math background. I found 4x4 matrixes trivial in a computer graphics course because they were taught with proper examples in terms as they applied to camera and transformations. We re-implemented a subset of the OpenGL pipeline. If you don't understand the math, you can't hope to possibly understand how a 3D rendering pipeline works.

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.

There are definitely cases where using polar coordinates or angles (with sin/cos/tan and their inverses) is the right tool for the job. The common problem with using trigonometry in software is that angles repeat every 2pi and tangents can overflow your math system (and in fact are undefined at 1/2pi and 3/2pi).

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.

Yeah, the advice shouldn't be "avoid angles", but "avoid discontinuities".

First, you have be able to spell "quaternions." :) I think you meant vectors, points, and 3x3 matrixes. 4x4 transformations have the advantages of specifying translations and scaling in 3-space where triples and 3x3 cannot.