Great post although it made me hungry for explanation what are the actual implementation differences between rotors and quaternions because I got the impression that we use exactly same real numbers to do exactly same things. We just imagine basis of this transformation space not as some 4 orthogonal vectors, just 3 orthogonal unit planes plus one real number for scaling.
Those bivectors just explain (incredibly, amazingly well) what quaternions are and why they have properties they have. It doesn't seem to change how you crunch the numbers to get what you want.
...
It's really great that you wrote that post. I feel like for the first time I truly understand rotations in 3D and know why I felt something fishy was going on with results of vector product and expressing rotations with them.
The results are going to be the same. The arithmetic involved is literally identical.
The real power of the GA version is that you can more clearly geometrically explain what is going on, and you can generalize everything to pseudo-Euclidean spaces or to lower or higher dimensions. GA gives you some more algebraic tools to work with, so when you are trying to write your proofs they are clearer and more concise.
I got a C- in Linear Algebra in college... I remember my Linear Algebra prof saying "maybe I'm being pedantic" when explaining a concept and I was like "wtf are you even talking about?"
I avoid all Math - and I think black boxes are great. The few times I've used functions with quaternions in game programming (I'm not a game programmer) they seemed really easy to use. I'm skeptical that a concept that is easy to understand for people with a Math background is easier to use in code for people like me.
If the results are going to be the same, then what's the possible benefit for any user of a 3D engine?
Things like the ability to "generalize everything to pseudo-Euclidean spaces or to lower or higher dimensions", algebraic tools and writing proofs are not relevant to the needs that a 3D engine serves - 3D engines are written to fulfil requirements of engine users (not even engine writers), who won't be doing such things, that's below the abstraction level that's handled by the engine. So from that perspective we're comparing GA-filled black box with a quaternion-filled black box, and either (a) the GA box has better performance; or (b) the GA box has different results that are arguably more correct; or (c) the GA box has a substantially easier API; or (d) the GA box is useless.
It seems to me that you might be aiming at the (c) benefit with all the arguments that this math is easier to understand, but I'm not entirely convinced based on the article; perhaps an illustration of the expected code differences in using a non-quaternion GA-based engine (are there any?) would be helpful. If we can have an engine/API that's easier to understand for beginners and that makes all the basic tutorials simpler, then that would be a nice thing to have.
From the possible options I listed above, (c), a substantially easier API.
On the other hand, if it's not exposed to the user, it doesn't particularly matter what structures and math that higher-level language uses behind the scenes to do what it does; most aspects of compiler theory are irrelevant for users of high-level languages.
Those bivectors just explain (incredibly, amazingly well) what quaternions are and why they have properties they have. It doesn't seem to change how you crunch the numbers to get what you want.
...
It's really great that you wrote that post. I feel like for the first time I truly understand rotations in 3D and know why I felt something fishy was going on with results of vector product and expressing rotations with them.