I think this is more subjective than the author makes it out to be. I take a third approach: You can change out Matrices for Quaternions. Then do almost every operation using these two types, and a few operation between them. The operation implementations are a mix of dot products, quaternion multiplication, trig etc.

I find this flow works well because it's like building arbitrarily complex transformation by composing a few operations, so easy to keep in my head. Or maybe I just got used to it, and the key is find a stick with a pattern you're effective with.

So:

> For example, you are aligning a spaceship to an animation path, by making sure the spaceship's z axis aligns with the path's tangent or direction vector d.

Might be:

  let ship_z = ship.orientation.rotate_vec(Z_AXIS);
  let rotator = Quaternion::from_unit_vecs(ship_z.to_normalized(), path.to_normalized());

  ship.orientation *= rotator;

I need to review for the sort of redundant operations it warns about, but from a skim, I'm only using acos for SLERP, and computing dihedral angles, which aren't really the basic building blocks. Not using atan. So maybe OK?

edit: Insight: It appears the use of trig in my code is exclusively for when an angle is part of the concept. If something is only vectors and quaternions, it stays that way. If an angle is introduced, trig occurs. And to the article: For that spaceship alignment example, it doesn't introduce an angle, so no trig. But there are many cases IMO where you want an explicit angle (Think user interactions)

Update with the big picture: I think the rotationAxisAngle example in the article is fine. The problem isn't that it exists and uses angles/trig: There are legit uses for that function! The problem is that it's not the best tool for aligning the spaceship. So: Problem is not that fn or angles/trig: It's using the wrong tool.

> You can change out Matrices for Quaternions.

Better use spin groups: they work in every dimension.