suppose you want to do global opperations you simply do the orders in reverse.
what I usually do is when reading in the mouse movements, I construct a rotation(axis angle form) with vector defined by (dx, dy) with a magnatude of whatever you want to define, use this delta matrix(or quaternion) to rotate the object around the global x or y axis note the way I defined it doestn' give room for z axis rotation, but it does't detract it's usefullness, I gonna post a like to a program I wrote in school, tell me if you think it's object movement code is reasonable. To rotate with global axis, you'd do something like this


//initialize
orientation = initial orientation/scale


//read in keys
deltaQuaternion = quaternion(dx, dy,0, angle);


//draw
orientation = deltaQuaternion*orientation;

//convert to matrix and draw with it
loadMatrix(orientation);
//draw ...

in the program I'm linking to you, if you press space it gives you two teapot to play with, move them to different orientation and press i to see quaternion interpolation from the two orientation.

here is the progarm
http://ieng9.ucsd.edu/~twernett/Quaternion.exe


if it doesn't work, it's because you need the glut dll files
http://www.xmission.com/~nate/glut.html


try it and see if it has the kinda movement you want, if it does I'll post up source if you request it.


**Quote**
Are you sure about that? I was under the impression that he wants to be able to rotate his object about any global axis, regardless of the object's current orientation. I'm not clear on how you would do this with Euler angles, regardless of order of operations.
**

you can do rotations around the global axis using eular angles, why not? you just have to read them in the oposite manner, this is bottom to up for open gl.

**Quote**
just because something looks like gimble lock doesn't mean it is
**

you're right, but this problem doens't look like gimble lock at all, you'll notice gimble lock, when your camera get's "stuck" into an orientation that isn't easily escapable. just rotation in a manner not expected is not gimble lock. of course these problems could also be caused via the view vector matching exactly with the up vector in your camera construction.


btw how do you quote?


Tim

[Edited by - timw on September 1, 2005 11:57:38 AM]

Hey

For camrea controll look at:
Quaternion Camera Control
(Full source code in C)

For quoting:


V

I should note the main reasons quaternion camera dont suffer from this problem is that there is no prefered up direction and thus your prefered up direction and view direction can never align, like I said above. but for your problem, that is just rotation of objects, I think you could do without quaternion, unless you want to do interpolation b/w orientations, in which case it works nicely. but you're not doing that as far as I can see.

thanks for the tip Vuli..

Tim

jyk

Quote:
Are you sure about that? I was under the impression that he wants to be able to rotate his object about any global axis, regardless of the object's current orientation. I'm not clear on how you would do this with Euler angles, regardless of order of operations.

you can use Matrix to rotate this object about the axis, I know it's a mindscrew these gimble lock, but here is why.

suppose we implimented this by keeing track of 3 rotation variables. one about the x,y,z. and if we rotated the object about the y we'd increase or decrease our y rotation value, and the same for x, and z. We then make the orientation matrix by concatining the rotations M = X*Y*Z or whatver order float you boat.

ok so with this system we DO have gimble lock. because it's relying on interpolation of the x, y, z values.

However, if we implimeted it slightly differently like I did above, replace quartinion with matrix and vola, it will work. in this system we aren't relying on interpolated x, y, z values, rather we are just taking the last orientation and concatenating another rotation to produce another orientation. in the system above we only ever have 3 rotations to represent our orientation, in this system, we have an arbitrary amount, in fact every time we move it we add another rotation, so our matrix is actually a concatination of MANY rotations, not just 3. at this point we at least realize that the two aren't mathematically equivilant. here is the method above slightly modifed for clarity.

//initialize
orientationMatrix = InitialOrientation;

//input
if(rotation == x)
rotationMatrix = EulerX(smallangle);
else if(rotation == y)
rotationMatrix = EulerY(smallangle);
else
rotationMatrix = EulerZ(smallangle);

//draw
orientationMatrix = rotationMatrix*orientationMatrix;
glLoadMatrix(orientationMatrix);
//plot points.....
...
//reset rotation matrix till next input(so it doesn't keep rotating)
rotationMatrix = Identity;


I'm hoping you see now how we can use euler angles to solve this, we just don't keep a running interpolation of our orientation. in this respect the method here and the method I showed in the previous post are equiviliant(except of coures, one uses matrix and another uses quaternion) gimble lock is not a dificency of euler angles, just how people use them, it's people deficency, lol.

Quote:
This is the classic problem.
You convert quaternion to matrix and then you multiply it with another matrix.
This matrix multiplication can give you gimbal lock.
You've broken the "quaternion flow" and introduced flawed matrix operation.

umm not really suppose I have two quaternions one represents a rotation of 90 degrees about the x axis, and another represents a rotation of 45 degrees about the y. call these q1 and q2 respectivley. and suppose we have two matrix that represent the same thing. and we do this

M = M1*M2
q = q1*q2;

if I converted this quaternion to a matrix that matrix would be M. if I converted q1 to a matrix that matrix would be M1, if I converted q2 to a matrix that matrix would be M2. a quaternion is just an orientation, so is a orthonormal matrix, so is an axis angle. these are all equivlient here, you can make camara systems using matrix multiplicaiton that are not prone to gimble lock(using the system above with the order of operations reversed), the only problem is after constantly concatinating the matrix with others numerical drift will tend to "un-orthonormilize" the matrix. if you're familiar how to transform points DIRECTLY in quaternion form, you can easily see why it's so.

Tim

[Edited by - timw on September 1, 2005 2:32:31 PM]

@tim: I don't think we're in disagreement about anything. I had thought that the OP was constructing his matrix/quaternion from scratch each frame, in which case changing the order of operations wouldn't solve his problem. But now that I re-read his original post, I'm actually not sure what he's doing...

lol come to think of it after re-reading the post Im not sure either, heh. care to enlighten us abolfoooud?

abolfooud2 the saver is back :p
i fell down laughing after reading ur posts guys.
i appologise if i coused any misunderstanding.

the functionality i am looking for is exactly like the one in timw's teapot example. that is what i am after. i want to do the same effect as rotating the teapot around the global axes not its local ones.
so would u mind timw to post pieces of the code in a new post or to add to ur kindness and give it to me :D ?

my initial problem was with the quaternion-to-matrix conversion. i did
construct the two quaternions adn directly converted them to matrices which made the quaternions' benifit inapplicable, since i did the converion directly before multiolying them. then, i perfomed the multiplication of the covnerted matrices using glMultMatrixf(); so, i encountered at the end to the same problem as rotating using glRotate*().

ur posts guys showed me where i was stuck and i was trying to solve my prob out until i sow timw's example where i started crying :'( that is exactly what i was trying to do :(

thanx for help any ways
abolfoooud

Yello

Quote:Original post by timw
jyk

Quote:
This is the classic problem.
You convert quaternion to matrix and then you multiply it with another matrix.
This matrix multiplication can give you gimbal lock.
You've broken the "quaternion flow" and introduced flawed matrix operation.

umm not really suppose I have two quaternions one represents a rotation of 90 degrees about the x axis, and another represents a rotation of 45 degrees about the y. call these q1 and q2 respectivley. and suppose we have two matrix that represent the same thing. and we do this

M = M1*M2
q = q1*q2;

if I converted this quaternion to a matrix that matrix would be M. if I converted q1 to a matrix that matrix would be M1, if I converted q2 to a matrix that matrix would be M2. a quaternion is just an orientation, so is a orthonormal matrix, so is an axis angle. these are all equivlient here, you can make camara systems using matrix multiplicaiton that are not prone to gimble lock(using the system above with the order of operations reversed), the only problem is after constantly concatinating the matrix with others numerical drift will tend to "un-orthonormilize" the matrix. if you're familiar how to transform points DIRECTLY in quaternion form, you can easily see why it's so.

Tim

I may have been a little to general, let me rephrase:

You've broken the "quaternion flow" and introduced POSSIBLY flawed matrix operation.

I was not trying to say that matrix operations are direct road to gimbal. Quaternions are just MORE elegant way of making sure gimbal doesn’t bite your ass :).

Quote:...gimble lock is not a deficiency of Euler angles, just how people use them, it's people deficiency...

umm not really ;)
The Euler angles are deficient since they evaluate each axis independently in a set order, which causes the problem. So, people are really deficient in solving the Euler angle deficiency, rather then just being deficient themselves :)

BTW we are solving the problem abolfoooud2 does not have :D

V

Quote:
umm not really ;)
The Euler angles are deficient since they evaluate each axis independently in a set order, which causes the problem. So, people are really deficient in solving the Euler angle deficiency, rather then just being deficient themselves :)

I agree with you, I think I considering a different problem, just using the wrong words.

Quote:
I was not trying to say that matrix operations are direct road to gimbal. Quaternions are just MORE elegant way of making sure gimbal doesn’t bite your ass :).

I agree with you again, but you can still build a camera with gimble lock if you only use ONLY quaternion opertions. for example, if you still used euler angles in a quaternion representation, which to be honest, it seems he may be doing in the first post, not sure tho.

Tim