pengkuan said:
When you rotate points at runtime, do you use quaternion multiplication like q*p*q^-1?

Traditionally, if we rotate many points, we mostly use 4x3 or 4x4 matrices. The upper 3x3 part can represent not only orientation, but also non uniform scale, shear, or any affine transformation. The 4th row is a translation vector, so we can compose any transformations we want into just one matrix. This makes it a clear winner in many regards.

Due to performance increasing faster on doing math than with reading memory, it has shown quaternions can be faster in some cases, e.g. to transform the vertices of a character on GPU, although it requires significantly more moth operations to rotate a vector. Another big reason is quaternions taking less CPU registers.
Typical code looks like so, implemented using 2 cross products:

t = 2 * cross(q.xyz, v)
v' = v + q.w * t + cross(q.xyz, t)

Iirc that's some minor optimization over the textbook sandwich multiplication, if at all.

But i think matrices still do the bulk work of our stuff in general.

However, bulk work is not really interesting, or the reason why we would like some more options to deal with 3D rotations.
Personally i work a lot on inverse kinematics solvers for characters, and that's a field where we rotations dominate, and many related problems appear.
And i do not rotate thousands of vertices, just single digit numbers, as i work just on few bones, target points and orientations, etc. Thus quaternions are mostly the better tool.
But - like almost everybody - i do not understand them in full detail. That's just a bad feeling.

To sum up my personal history regarding 3D rotations:
I learned matrices first, but it really was hard to accept we need so many numbers and operations, just to orient the bones of my character skeleton, and to transform all it's vertices. I even tried to come up with some ‘better way’ myself, back then.
Later i learned about quaternions, and i was fascinated. It was the better way i wanted - less data, we can do spherical interpolations, easy construction from axis and angle or from vector to vector. But it's inner workings remained a mystery til the current day.
Much later i figured out that i can do everything quats can do with matrices too, if i wanted. That's the point where understanding of 3D rotations is pretty solid, i guess.

And i guess this sums up our problem: We do not really expect to find faster methods, but we would love to understand our tools.
I've never heard about rotors before, and after watching the video above, i have some hope maybe this is a concept to enable such better understanding for me.

If you ask about how quaternions work, the answer often is ‘it's a 3D version of complex numbers’.
But this does not help.
First, complex numbers are itself a strange concept to the regular guy, which may lack education in math, like i do. Imaginary numbers? Square root of negative numbers? What?
But some years ago i picked it up when working on vector-, line-, or crossfields on meshes. I've learned it's just a concept, wrapping up the math dealing with 2D vectors and their angles. It's no new math at all, just a concept convenient to use. I like it.
But it still does not help to understand quaternion multiplication.

As a self taught amateur, i even tend you think you math guys tell me quaternions are like complex numbers, just so you can avoid to admit you don't know yourself, by using terms which sound even more fancy, hahaha :D
A similar issue is with Spherical Harmonics. You read they are a spherical version of a fourier series, but again: This just tells the obvious, not the difficult and interesting spherical part.

That just said to confirm: Yes, we have some problems with 3D rotations. It's more mentally than technically, though.
One big practical reason is 3d rotations are not cumulative, while in 2D they are, as they share just one possible axis. That's also a reason why the ‘complex number explanation’ ends up disappointing to the noob.

In this regard: Thanks for trying to help, and thinking of us and informing us. Even if i did not find new enlightenment, maybe some others do.

pengkuan said:
With the direction frame of my orientation system, I can rotate a point this way: new point= old point * [B], with B being a 3x3 matrix. I have put the formula in the joined image.

Ah ok, that's what i have assumed and expected.

@JoeJ

Thank you for explaining patiently so many things, which teach me a lot about your world of game programming.

To be honest, I was developing 3D complex number and the people who did fractals were delighted by it because they could convert 2D equations into 3D equations for fractals and create 3D fractal objects never seen before. As 3D complex number has 3 components, can be multiplied and divided like quaternion, I thought it was maybe a good idea to do the computation with 3D complex number that was done with quaternion which has 4 dimensions.

JoeJ said:
One big practical reason is 3d rotations are not cumulative, while in 2D they are, as they share just one possible axis.

By the way, 3D complex number is cumulative when they multiply together , just like 2D complex.

But I have learned from you that you have all the tools you need and thus, my 3D complex system is not suitable. I realize that my idea turns out to be wrong in this world. So, I give up here.

Thank you again and best wishes.

pengkuan said:
By the way, 3D complex number is cumulative when they multiply together , just like 2D complex.

That's interesting!

My impression of your 3D complex numbers comes just from a single sentence from your paper. (Did not look up the other paper entirely about them):

Initially i thought this represents a sequence of 2 orthogonal rotations. But now i'm no longer sure.

I can imagine this is interesting for fractals, because we can not extend the Mandelbrot formula to 3D, as it requires cumulative property.

Well, it tried myself to find some 3D fractal formula building on Mandelbrot, so i'll look it up… : )

@JoeJ 

JoeJ said:
That's interesting!

JoeJ said:
I can imagine this is interesting for fractals, because we can not extend the Mandelbrot formula to 3D, as it requires cumulative property. Well, it tried myself to find some 3D fractal formula building on Mandelbrot, so i'll look it up… : )

Here is the formulae and image of 3D Fractals:

1 Mandelbrot power=2

2 Mandelbrot power=3

Oh, dear.

I've seen variations on this theme before, but don't want to go there.

There are some issues when you need to integrate rotations, which comes up in physics engines. It's possible to integrate quaternions, which you do when you apply an angular velocity times time to a rotation. This can result in slight denormalization. Transformations which are supposed to be affine become slightly non-affine. This is also an issue when you repeatedly apply a rotation to a rotation, and accumulate rounding errors. You can renormalize quaternions, but it's kind of a hack. A homogeneous representation that inherently stayed affine despite rounding errors would be helpful. Some systems use quaternions where the fourth component is always recomputed rather than stored. But that costs you a square root.

It's been many years since I had to work through that, but I once did physics engines and had to deal with such problems.

I remember a talk with a physics dev, and he said something like ‘Rotations do not really exist. Naturally, any particle tries to move in a straight line. But it's interactions with other particles to form a rigid structure, or external forces like gravity, can lead to non straight trajectories like arcs.’

That's quite an interesting way to look at it.

I think you're pushing at the wrong optimisation potential.

To summarise the way things are normally done, there is typically a single “world space” or “global space” modelview-projection (MVP) matrix which concatenates all the transforms required to position objects in a scene, relative to the position and orientation of a virtual “camera”.

From there each object may have it's own relative position and orientation, which - irrespective of how they are sourced and computed - are typically stored as a “local space” or “object space” matrix. There may be other matrices for bone transforms with skeletal animation but I'll ignore them to keep things simple.

We prefer matrices for storing these transforms because rotations are not the only transforms that can be applied. Objects are also positoned ("translated"), scaled, they have projection from 3D to 2D space applied; a matrix is just the best representation for storing all of these transforms.

Each vertex in an object has it's own position, typically relative to an origin of {0,0,0}.

By using matrices, all transforms can be concatenated to a single matrix per object, and then the object can be correctly positioned in a scene by just doing a series of simple and fast vector-matrix multiplies.

So any proposal to speed up calculation of rotations is actually speeding up something that's not even a bottleneck to begin with. It's only done once per object, there's no performance to be gained. And it's also important to not forget those transforms other than just rotation, which other “faster” or “more compact” representations often miss. There's a reason why matrices have been preferred for ~30 years, and that's because engineers are actually not stupid nor in the pay of nefarious forces - they're genuinely the best representation.

Wait, what? 3D numbers?

Can you please send me a copy of your paper? My email is mailto:sjhalayka@gmail.com​

Looking forward to hearing from you!

taby said:
Can you please send me a copy of your paper?

It's here.

P.S. what do you get when the iterative equation is z = sin z + c sin z?

I also am interested to know how many multiplication and addition operations does it take?

I recently did a similar paper:

https://www.techrxiv.org/articles/preprint/Calculating_fractal_sets_in_n_1_embedding_dimensions_without_the_use_of_truncation/19425989