Is there a Quaternion master ?

[Zeross]

Well this time I'm lost here is what I'm trying to achieve :
I've got an object inside a cube mapped skybox, I want to be able to rotate the object with the left mouse button (using SGI trackball library) and to move around the object with the right mouse button.

To achive this I'm using two quaternions, one updated when the mouse is moved with the left button (ModelQuat) and the other when the mouse is moved with the right button (EnvirQuat). Then in the draw method I draw the skyBox using EnvirQuat then I multiply the two quaternions, convert the resulting quaternion to a rotation matrix which I load in modelview and draw the object. The result is almost what I want the problem is that while the environment is not moved everything is Ok I can rotate my object as I want, but when I move the camera to look my object from above for exemple then it seems that I've lost a degree of freedom. I thought that using quaternions is the way to solve this problem, so I guess I'm doing something wrong :?

Any way to achieve what I want ? It annoys me it seems so easy but I can't get it to work :x

[pcchen]

How do you update the quaternion? Do you use fixed axes? If so, you may still encounter gimbal lock.

[Zeross]

Like I've said I'm using SGI files for simulating a trackball so the quaternion is updated like that :
trackball(m_LastQuat,
(2.0 * m_BeginX - (float)m_Width) / (float)m_Width,
((float)m_Height - 2.0 * m_BeginY) / m_Height,
(2.0 * point.x - (float)m_Width) / (float)m_Width,
((float)m_Height - 2.0 * point.y) / m_Height
);

m_OldPosX = m_BeginX;
m_OldPosY = m_BeginY;
m_BeginX = point.x;
m_BeginY = point.y;

add_quats(m_LastQuat, m_CurQuat, m_CurQuat);

and you can find the trackball source code here : http://www.vr.clemson.edu/~andrewd/courses/graphics/examples/gtk-gl/trackball.c

[Simon F]

Zeross,
Have a search for Ken Shoemake's arcball article that was in Graphics Gems. (The source is sure to be on the net somewhere). It sounds like the sort of thing you're after.

[Zeross]

Yes I've seen a tutorial on this on NeHe but I don't think it will solve my problem : when I will move the camera then the rotation of the object will still be problematic, no ?

[Simon F]

I must admit I haven't fully understood your description of the the problem. Just a silly question, are you combining the increments to your individual quat's in the correct order? It seems to me that one should be pre-multiplied and the other posi-multiplied.

[LeGreg]

Quaternion is not *the way* to solve the lost of one degree of freedom at 90 degrees, it's just a common urban legend. Quaternion represents just the same rotations as Euler or matrices.

In fact in your case it's the way you interpret your rotation mouse movement that matters.
Think incremental rather than absolute.
If you go from a euler description that means if you interpret mouse coordinates as mere absolute theta and phi to a quaternion representation, then your quaternion won't be able to have more degree of freedoms as your original representation because it's the same orientation.

Si tu veux je le fais en français:
Interprete tes mouvements de la souris comme des mouvements incrémentaux (Ã* ne pas faire si tu fais un simple FPS mais dans ton cas c'est ce que tu veux faire), donc conserve la rotation précédente (sous forme de quaternion ou sous forme de matrice, ça n'a pas d'importance), et multiplie lÃ* Ã* chaque mouvement par un quaternion ou une matrice qui représente un delta d'orientation fixe.

Q0 = rotation au temps zero
Qdelta01 = quaternion qui correspond au delta x et delta y (tu peux utiliser la fonction trackball pour faire ce calcul ça ne pose pas de problème)
Q1 = rotation au temps un = Q0 * Qdelta01.

Hope that helps
Grégory

[LeGreg]

Beware in most first person shooters we prefer to keep the sense of horizontality rather than have a perfect isotropic mapping of rotations.
For playability and personal sensitivity reasons: people keep their head up all the time except when they sleep or die. So you better map the movement of the mouse to absolute rotations.

On the contrary if you move an object into space, then horizontality doesn't make any sense, so you can forget about this.

I know it's confusing. If you want you can play with a playmobil or a gijoe and make them rotate the way you would like to rotate in your program and see which way suits you.

What is the interest of quaternions compared to matrix or euler angles ?

- Euler angles are more difficult to combine together (I don't even talk about interpolate), plus they have those singular points at poles. Positive point is that they are easy and natural way to represent rotations (much more than matrices, let not say quaternions).
- Matrices, can be combined with other transformations in transformation pipeline. Natural rotation representation for machines and graphic accelerators.
- Quaternions. More compact than matrices (matrices are mostly redundant when they represent a single rotation). They can be combined as easily. Plus you have this nice natural SLERP (spherical interpolation).

To give you an example, if you find an object in an arbitrary rotation and you want it to go to the natural horizontal rotation that most people prefer, then you can interpolate your quaternions. If you interpolate matrices then you can have garbage. If you interpolate quaternions using this simple SLERP formula, then you get the natural rotation movement on a sphere (chances are high it is the shortest path projected on the sphere too).

Of course matrices get linearly interpolated all the time for mesh skinning. But nobody said it was elegant.

LeGreg

[Dio]

My favoured way to represent transforms is using a position-direction-up vector set (I've seen this referred to as the look-at transform as well). I find vectors far easier to work with than matrices - they are real, physical quantities I can make easy changes to.

They're also convenient. Run forward at n units/frame? position += direction*n.

[Simon F]

Quaternion is not *the way* to solve the lost of one degree of freedom at 90 degrees, it's just a common urban legend. Quaternion represents just the same rotations as Euler or matrices.

Yes and no. IIRC the problem would occur when the method of representing the arbitrary rotation relied on a fixed order of axes such as {Rx, Ry, Rz} = "angle of rotation about X followed by rotation about Y followed by rotation about Z". That could certainly lead to gimbal lock. Of course, you could choose arbitrary axis order OR allow a list of multiple angles.

It's just that, IIRC, it's a bit of a pain to combine two sets of these specifications, eg {Rx1, Ry1, Rz1} and {Rx2, Ry2, Ry3}, into a single {Rx3, Ry3, Rz3} .

As you said, rotations obviously can be specifed by 3x3 matricies which then makes it very easy to concatenate multiple rotations - the problem is that the maths will drift due to precision issues and you will quickly end up with a non-orthonormal matrix, i.e. it's no longer a pure rotation.

You can post process the results every now and then to force the matrix to be orthorgonal and normalised, but this is nuisance.

Again, IIRC, the big advantage of quaternions is that they are easy to combine and also very easy to normalise thus making them ideal for incremental work,

[darkblu]

Quaternion is not *the way* to solve the lost of one degree of freedom at 90 degrees, it's just a common urban legend. Quaternion represents just the same rotations as Euler or matrices.

Yes and no. IIRC the problem would occur when the method of representing the arbitrary rotation relied on a fixed order of axes such as {Rx, Ry, Rz} = "angle of rotation about X followed by rotation about Y followed by rotation about Z". That could certainly lead to gimbal lock. Of course, you could choose arbitrary axis order OR allow a list of multiple angles.

It's just that, IIRC, it's a bit of a pain to combine two sets of these specifications, eg {Rx1, Ry1, Rz1} and {Rx2, Ry2, Ry3}, into a single {Rx3, Ry3, Rz3} .

As you said, rotations obviously can be specifed by 3x3 matricies which then makes it very easy to concatenate multiple rotations - the problem is that the maths will drift due to precision issues and you will quickly end up with a non-orthonormal matrix, i.e. it's no longer a pure rotation.

You can post process the results every now and then to force the matrix to be orthorgonal and normalised, but this is nuisance.

Again, IIRC, the big advantage of quaternions is that they are easy to combine and also very easy to normalise thus making them ideal for incremental work,

mm, my favourite meal is being served here.

what Simon says is my understanding of the matter, too. quternions can go astray just as rotation matices, but are indeed easily put back on track, whereas with rotation matrices orthonomalisation, although not a big deal either, is more a matter or ambiguity of concepts - you have a slightly non-orthonormal matrix which is meant to become orthonormal again - which of the axes are to be adjusted? - i.e. it's more a matter of convention. on a second thought, though, re-normalisation of quaternions can be as erroneous as picking the wrong convention to re-orthonormalise a rotation matrix: given one does not know the origin of the error accumulated in the denormalised entity, one can not know for sure that trivial re-normalisation gives the a 'correct' result (i.e. within some known error).

My favoured way to represent transforms is using a position-direction-up vector set (I've seen this referred to as the look-at transform as well). I find vectors far easier to work with than matrices - they are real, physical quantities I can make easy changes to.

transforamtion matrices are just as real, physical entities as vectors are - matrices repesent bases of spaces, where the axes vectors are defined in some outer, 'reference' base, and are arranged either by columns or by rows (depending on convention). of course, sometimes the base represented by a matrix may be inverted, but that does not change its nature (it's still a vector base), just its desired effect (in our mind only, i.e.)

[LeGreg]

Yes and no.

absolutely yes :)

What I meant is that he (zeross) tried to solve the gimbal lock by representing internally his rotation by quaternion. But he doesn't understand that going to quaternion the way he does doesn't solve anything.
Because once again he has a perfect mapping from euler angles to quaternion. His problem is not a problem of "orientation mapping" but a problem of "user input". Precision and interpolation etc are only secondary to that (he will probably hit them and then he will ask people "why do my model shrink in time when I rotate them ?").

So IT IS a urban legend or voodoo programming to think that by introducing quaternions in the process will get rid of gimbal lock.

In my second post I gave a list of reason why quaternions are good so I do not wish to destroy their true interest just to help clear a misunderstanding in the original post.

LeGreg

[LeGreg]

on a second thought, though, re-normalisation of quaternions can be as erroneous as picking the wrong convention to re-orthonormalise a rotation matrix: given one does not know the origin of the error accumulated in the denormalised entity, one can not know for sure that trivial re-normalisation gives the a 'correct' result (i.e. within some known error).

Your solution to that is
1 - renormalize frequently so you avoid glitches in animation when a renormalization occur.
2- The error in the process is not significant (in general case) because your inputs were not critically exact in the first place. Renormalization do just that: ensure that your quaternion or matrix or vector are normalized again and so that nothing shrinks or expand or distort when your only intent is to rotate.
3- Renormalization errors are nothing compared to the errors that happen let's say when you linarly interpolate a movement for mesh skinning.

Unless you drive some really precise and chaotic simulation, that's the most you can get through renormalization.

LeGreg

[darkblu]

yes, my whole secondly-thought remark was meant as a self-correction that re-normalization (of quats in our case) actually does not guarantee the desired rotation, only that there would be no extra transforms but some rotation. in this respect quats, as re-normalized as they could get, might not be as good for incremental work as originally suggested and initially agreed by me. i also allowed myself to generlise that as long as re-normalisation is implied, any spatial tool subject to it is prone to same/similar error issues. bottomline being, we all agree on the matter (it seems)

[Simon F]

Yes and no.

absolutely yes :)

What I meant is that he (zeross) tried to solve the gimbal lock by representing internally his rotation by quaternion. But he doesn't understand that going to quaternion the way he does doesn't solve anything.
I misunderstood what the OP was saying. Indeed if he's just emulating fixed axes with a quaternion then he is going to be disappointed :-)

[Joe DeFuria]

Crikey!

All I've got out of this whole conversation was:

blah...blah...blah...G.I. Joe....blah...blah...blah...

[Zeross]

Thanks everyone, problem solved :)
I was already doing incremental rotations by keeping the previous transformation as LeGreg suggested, but the problem lied in the way the trackball function worked I've modified it and now everything is Ok.

[LeGreg]

bonne chance :)

LeGreg

[Zeross]

pourquoi ?

[Dio]

transforamtion matrices are just as real, physical entities as vectors are - matrices repesent bases of spaces, where the axes vectors are defined in some outer, 'reference' base
It's a good point. I should have put quotes around 'real'. I'm not a mathematician, my background is in physics, so I can visualise and manipulate vectors 'til the cows come home - while I have no idea what the phrase 'matrices represent bases of spaces' means :).

Of course, this is just me demonstrating my stupidity. My experience with maths is mostly with mathemagicians, where three rules hold:
1. They always know an answer, but there's no danger of me understanding it
2. They invariably turn out to be right
3. Sometimes - rarely - there are hacks that they miss ;)

So I was describing one of the methods I've seen that maths fools like me might have a better time with if they find matrix math hairy.

[LeGreg]

pourquoi ?

ben juste bonne chance pour ton projet.

C'est tout.

LeGreg

[darkblu]

It's a good point. I should have put quotes around 'real'. I'm not a mathematician, my background is in physics, so I can visualise and manipulate vectors 'til the cows come home - while I have no idea what the phrase 'matrices represent bases of spaces' means :).

that be because my wording used in this case (and in 95% of the rest of the cases, i'm affraid) was pretty loose. a vector-space base would have been the correct term - a set of N linearly-independent vectors, defining the base of a coodinate system with N dimensions. you then pack those vectors the right way in a matrix (possibly with a homogeneous part) and voila - there's your matrix transformation ; )

Of course, this is just me demonstrating my stupidity. My experience with maths is mostly with mathemagicians, where three rules hold:
1. They always know an answer, but there's no danger of me understanding it
2. They invariably turn out to be right
3. Sometimes - rarely - there are hacks that they miss ;)

So I was describing one of the methods I've seen that maths fools like me might have a better time with if they find matrix math hairy.

while this board is yet to see a 'demonstation of your stupidity', i absolutely second your three points of view at math (me being a math mediocrite at large), just that with linear algebra it's pretty much an intuitive process - one can learn to envision pretty much any entity from it, includingly matrix transformations : )

ed: yet another example of my inabily to write anything sensible in a human language

[Dio]

Ah, now that starts to sound like some of the stuff I didn't understand in my plasma physics (which is where 'real' vectors get really hairy). :) I can hear the words 'eigenvector' and 'eigenvalue' approaching... like the front of an oncoming train.

The general agreement on that course was that Maxwell was an evil git.

[Simon F]

Ah, now that starts to sound like some of the stuff I didn't understand in my plasma physics (which is where 'real' vectors get really hairy). :) I can hear the words 'eigenvector' and 'eigenvalue' approaching... like the front of an oncoming train.
Funnily enough, I just wrote my own routine to find the principal eigenvector - quite important for texture compression (VQ, S3TC, and PVR-TC).

[Zeross]

pourquoi ?

ben juste bonne chance pour ton projet.

C'est tout.

LeGreg

Ah ouf tu me rassures j'ai cru que c'était une mise en garde contre un éventuel futur problème. En tout cas merci pour tes conseils et pour tes encouragements :)

[Dio]

Funnily enough, I just wrote my own routine to find the principal eigenvector - quite important for texture compression (VQ, S3TC, and PVR-TC).
See point 3 above ;)

[Simon F]

Funnily enough, I just wrote my own routine to find the principal eigenvector - quite important for texture compression (VQ, S3TC, and PVR-TC).
See point 3 above ;)
I don't quite get what you mean although I think my new code falls into a "sort of hack" category. I had been using an "off the shelf" routine that found all the eigenvectors when I really only wanted the biggest one. This is what the new code does and has the big advantage of being very simple. I based it on a hint Konstantine Iourcha gave me while at Siggraph.

[Dio]

Ah, well, Konstantine is the mathemagician. Original and best. Whenever I say 'It Depends' it tends to come out in a Russian accent nowadays.