Quaternion Rotations in 3D Java OpenGL

Shared Code
#21

[quote]The point you seem to be missing is that those Euler angles need to be applied to the object you are rotating
[/quote]
yep I believe I probably missed something…

ok, I try to better explain myself:

your object rotation is set using the following sequence of rotation rx,ry,rz (euler ok ?)
you can go in a pos A with euler angle but you can also go in a pos B ok ?
so to go from A to B it is rx+=rxb-rxa, ry+=ryb-rya, rz+=rzb-rza ok ?
and what you have to do is to compute rya,ryb,rzb and that can be achieved

you can go from one pos to another applying rx+=drx,ry+=dry,rz+=drz, no ?

once again I really dont understand why you point that one (link)

[quote]the last axis is processed one of the axis could be aligned to another,
[/quote]
this is not possible as explained above Axis are rigid, you cant rotate one without rotate the two other, or you are confusing world and local space.

when you rotate in any direction you began to influence other rotation, as if you rotate around x and around y then the amount you rotate around y depend about the rotation you made around x basically
rotate arround x==0 => your axis are aligned and rotating around y is not affected 100%
but when you start to increase rx it become false and rotation around y is no more 100% it decrease and reach 0 at 90°. the gimbal lock is just the end of a degenration of your rotation axis, but this doesn’t lock anything and this particulary does’nt avoid any rotation even if you set your object rotation using three consecutive world space rotation.

EDIT:
ps: I was just asking what problems it can cause (this is this point that I missed the most)?

but finally you point that one too, with one I fully aggree.

[quote]To avoid Gimbal lock completely checks need to be placed in code whenever there is a chance of it occurring, or alternatively a different way of rotating can be used
[/quote]
but once again, this seems for me to results from a confusion ( or probably mine confusion ) about performing a world or a local object space rotation. because once you have made one rotation even small all your axis become not aligned to world one and so performing any more rotation doesn’t make what you expect it should do, but this become to be true when you start any rotation, I mean if you call pitch the rotation around x and you have performed a roll rotation before, your picth rotation is affected and is already false and become completly false (0%) at 90% because you try to perform a rotation in world axis and one of your ocal axis has become coolinear to a world axis wich is different then the one it was colinear with at init time.

so when your perform the sequence rx,ry,rz you must keep in mind that it is not directly local rx,ry,rz and that if you want to rotate around any of the three axis x,y,z you have to read it back not increase rx or ry or rz. but that’s only a confusion if you try to do such (IMHO)

NB: I believe it exist , ofcourse, as I have hear this term a lot of time,but what I am just trying to understand is when ? it cause problem and how ? in 3D software as I understand the problem in a gimbal system as above but not why it should/can be same in 3D software that allow us to put an object in any other rotation pos immediatly and so to rotate to any pos at anytime.

#22

my question is more what do you mean ? what anybody means when he said “It can suffer of gimbal lock” or something like “you may have a gimbal lock” etc ? what’s happend then ? I have developped a 3d software that use only euler positioning (I thinks this is that) and if I am going to suffer from anything I want to know, do I will have scare on my skin or anything else, what does that mean in 3D software and what problems it can cause ? my research is more to know if I have to care about that ?

EDIT:
seems there is a good explanation on difference of local and world there : http://en.wikipedia.org/wiki/Euler_angles#Other_composition_of_movements_equivalent

and this section is interresting too :

also an other problem then the gimbal system lock is described there but once again not applicable to 3d software :

[quote]For example, assume a level sensing platform on an aircraft flying due north has its three gimbal axes mutually at right angles, i.e., Roll, Pitch and Yaw angles each zero. If the aircraft pitches up 90 degrees, the plane’s and platform’s Roll axes become parallel to the Yaw axis, and changes about Yaw can no longer be compensated for. This problem may be overcome by use of a fourth gimbal, driven so as to maintain a large angle between Roll and Yaw gimbal axes.
[/quote]

and about quaternion and euler this one can help :
http://www.euclideanspace.com/maths/geometry/rotations/conversions/quaternionToEuler/

#23

:frowning: Using quaternions like Euler angles and converting them into Euler angles at the end doesn’t solve the problem.

Watch this (it is a bit approximative about the matrices):
http://www.univie.ac.at/cga/faq/angles.html

#24

[quote] Using quaternions like Euler angles and converting them into Euler angles at the end doesn’t solve the problem.
[/quote]
I trust you that it doesn’t, but this would be easier to know what problem we are talking about ? I never had anyproblem with quaternion or euler …

#25

I spoke about the gimbal lock, I thought it was obvious.

#26

Lets say the user of the software doesn’t know about Gimbal Locks, what inconvenience or practical problem will the presence of a Gimbal Lock create for the user?

In other words, why does the user of DzzD’s programs (rather than DzzD) care about whether or not his code might have Gimbal Locks?

#27

Let’s say you have this skeleton. You make a node tree of the limbs. Now when some nodes have specific angles, it becomes impossible to rotate the sub nodes along a certain axis.

At least, that was why I read up on Gimbal Lock to keep my little robot men walking across the screen pointing at stuff and grabbing things.

#28

[quote]In other words, why does the user of DzzD’s programs (rather than DzzD) care about whether or not his code might have Gimbal Locks?
[/quote]
yup, that’s exacly the question, aswell as why it is said something like “3d studio max suffer from gimbal lock”…, I use this software and other 3d tools and never had trouble on rotations.

[quote]Let’s say you have this skeleton. You make a node tree of the limbs. Now when some nodes have specific angles, it becomes impossible to rotate the sub nodes along a certain axis.
[/quote]
ok, so I assume it is a lock on rotation that made impossibility to rotate in one direction when certain condition are meet ?

the first idea I had about software gimbal lock was like Riven explanation : impossibility to rotate on certain condition. but I get some doubt after making further research on it, there is not really an official and clear explanation of what is a 3d software gimbal lock.

Making some further research on gimbal lock due to this thread it seems that it is become a term used in a lot of differents situations, and it is now clear for me that it is logical in the reallity as the gimbal system or the plane example.

so we can say that in 3d software it is used to define a situation of being unable to rotate in one direction wich seems to be the most used to define gimbal lock in 3d software.

so what I have tried to explain before is that : “being unable to rotate in one direction” is not related to the use of euler angle, euler angle doesn’t cause any lock while you know in wich space you are working
and what you are doing and while you keep in mind that performing the following world rotation rx,ry,rz is different to perform the following local rotation rx,ry,rz.

and “being unable to rotate in one direction” is just a very logical consequence of trying to rotate around an axis wich is not the one you think it is.

eg: a plane that is going straight down (nose going very down)
rotate in world space around y (with y up) it rotate in local space around z (with y forward) but rotating in local space around y make the plane turn right or left.
and if the plane is going forward all is magicaly working fine in local aswell as in world space.

NB: sorry If you find me too long on that subject, but I found it is a lot more interresting that it appear at first and I really want to understand the whole problem…

#29

Maybe the following example will help:

First of all: (0,1,0) is up

Again, we have that skeleton, and we want to control the hand, which is attached to the lower arm, the upper arm, the shoulder/torso.

Without rotation each arm stretches to each side (-X … +X), with the back of the hands facing up. Now rotate the shoulder/upperarm joint 45deg, so that there is an angle of 90deg between the arms. Now rotate the upper/lower arm joints 90 deg - the 2 upper arms and 2 lower arms form a rectangle now, pointing forward. Rotate the upper arms 60deg down. The skeleton is now standing as if he holds his belt.

Now try rotating the hands on the axis of the lower arm. (the Y axis in local space, as the hands go ‘up’ from the lower arm).

And indeed, this has nothing to do with euler angles, as you get the exact same problem with matrix concatenation.

For clarity, this is what your scenegraph would look like:


torso
 - translate along +X axis (neck to R shoulder joint), make rotations rotate, attach upper R arm
    - translate along +Y axis (shoulder to upper/lower arm joint), make rotations rotate, attach lower R arm
       - translate along +Y axis (upper/lower arm to hand joint), make rotations rotate, attach R hand
 - translate along -X axis (neck to L shoulder joint), make rotations rotate, attach upper L arm
    - translate along +Y axis (shoulder to upper/lower arm joint), make rotations rotate, attach lower L arm
       - translate along +Y axis (upper/lower arm to hand joint), make rotations rotate, attach L hand
#30

I try to understand… but get stuck on : “Now rotate the upper/lower arm joints 90 deg”, what next ?

EDIT: step 3 ok ?

EDIT 2: I have modelized a gimbal system, so box is linked/child to the yellow axis, yellow axis is linked/child to blue gimbals , blue child of green gimbals and green child of red gimbal, all object are shown with rotation==0

so what can I do that will produce the lock bug (the 3ds file is available, just rename gimbals.3ds.txt to gimbal.3ds) ?

#31

also I have made an online 3D Gimbals demo (little messy, I reuse the viewer3D), source are available to download and it can be easily updated / recompiled for testing.

key 1,2,3 respectivly rotate gimbals 1,2,3, mouse can be used to rotate the root object (all scene but excluding the main light).

in the windows status bar you can read the current euler rotation for box (rotation relative to its parent/ to its local space), wich doesn’t change as expected as we only change rotation on parents objects.

to test/modify just look at the method called render3DWorldSpace.

http://demo.dzzd.net/GIMBALS/

#32

Lol! I like your style! ;D