15 comments

[ 0.22 ms ] story [ 46.8 ms ] thread
While a related but more advanced topic, I still can't quite intuit quaternions. But of course we're all fortunate to not need to understand them completely to use them.
Here's how I think about quaternions:

1) using complex numbers: A unit complex number (having its length/magnitude/absolute value equal to 1) form a circle, this circle corresponds to all 2d rotations The result of multiplying two unit complex number corresponds to combination of two 2d rotations. You can apply the rotation to a point in complex plane by multiplying that point by unit complex number that corresponds to a rotation

Quaternions are the same as complex numbers, but instead of having one imaginary part they have three, and they have slightly different rules of multiplication. Quaternions of magnitude one form a 4d sphere, this 4d sphere corresponds to all 3d rotations. The result of multiplying two unit quaternions corresponds to combination of two 3d rotations. You can apply the rotation to a point in 3d space using slightly different multiplication.

2) not using complex numbers Ine of the ways to represent 3d rotations is to choose an axis direction and and angle of rotation (surprisingly, this can represent all 3d rotations) A unit quaternion representing this rotation will have its three imaginary parts ijk equal to sin(angle)*(axis direction vector), and the real part equal to cos(angle) There are funny rules about how you can multiply these quaternions, and this multiplication will produce a quaternion that represents the rotation.

(comment deleted)
If you're wondering why the 3d cube doesn't quite look 3d, it's because the perspective transform hasn't been applied. Imagine taking a camera's view frustum (the rectangular "cone" from a camera's POV) and then re-forming the frustum and to be a unit square, while non-linearly squishing all of the geometry inside of the frustum as it turns into that square. The result would be that vertices of geometry further away from the camera would shrink towards the camera's vanishing point. Rendering this result would make geometry appear to be in perspective.
Also if you are wondering why the UI feels so horrible, it is because it is horrible.

In particular, it does not feel as if you were spinning a globe with your finger, because you need better math to do that: quaternions.

Play with this[1] and just feel how much better it is.

I tried to make the source understandable, but there are many, many, many other implementation of the Arcball interface out there. Find an explanation and code that you like and roll with that.

[1]http://romankogan.net/math/arcball_js/index.html

Woah, all this is so complicated! I would rather have them individually explain what each variable/math stuff does here to know its importance. Can anyone explain it?
It's needlessly complicated, and a horrible way both to understand and code rotations in 2D and 3D.
TL;DR: don't read this article, it is amazingly bad. Avoid trig. Look up "arcball interface"[0].

-------------------------------------------------------

Strong opinion from a math PhD/SWE:

You'll be better off not reading this at all than learning about the subject from this page. You'll have to un-learn it afterwards.

Most importantly, whatever you do, please NEVER write a 3D rotation function and UI this way. It is horrible for many reasons I won't go into here. DO write and use the so-called arcball interaface. Here's an implementation you can play with in a browser[0]. Try it now!

The article is is amazingly bad: not only it is not the right way to think about rotations, it's also bad computationally, features bad code, and nothing is said of the right way to do these things (i.e. how it's actually done by anyone who deals with it).

It also features some "magic math", i.e. unexplained trig formulas. Feel confused? You should be, unless you know this stuff already!

Rotations aren'ta reason to learn trigonometry; if anything, it's a reason to avoid trig. In fact, you should avoid trig when you can. (People smarter than me say so too[1]).

Here are the subjects one need to learn to actually deal with rotations:

* Linear algebra. Rotations are orthogonal transformations. And by using projective coordinates, translations are linear maps. OpenGL stack is all about 4 x 4 matrices!

* Complex analysis and quaternions. All complex number are is rotations & scaling in 2D (the sqrt(-1) stuff is not even necessary to define them). Quaternions generalize complex numbers, and provide an efficent way to interpolate rotations in 3D. Again, see[0].

* Lean about Euler Angles so that you know to not use them.

As a bonus, the unexplained trig identities (like the formula for sin(a+b)) come off naturally from either matrices or complex numbers.

Note that this is not all there is to it; I still used trigonometry in that example. This is altogether not necessary, see Inigo Quilez's article [1].

Most importantly, understand that the operation "rotate an object so that it points in that direction" doesn't require neither angles nor trigonometry. You just need a way to encode the direction (as a vector, quaternion, etc).

[0]http://romankogan.net/math/arcball_js/index.html

[1]http://www.iquilezles.org/www/articles/noacos/noacos.htm

You're pushing arcball really quite hard across this discussion, but it's just one of many ways of handling interactive rotation of an object, and the one used in the article (give or take accumulating inaccuracy) is fairly normal, too. Certainly, though, the article will not really help anyone aspiring to write a 3d engine of most any kind.
Arcball has some kind of gimbal lock - if you drag far enough it stops rotating. Maybe there's a reason for that, but it feels wrong.
Why is pmouseX subtracted from mouseX? And why is pmouseY subtracted from mouseY?
They're using the difference in mouseX (or mouseY) to dictate the amount to rotate the object. To do that, you subtract it from the previous one (mouseX-pmouseX).