I have been reading some posts about rotation around the fixed axis and I have some doubts.
If we want to rotate in the global coordinate system, we need to premultiply the matrix and if we want to rotate in local coordinate system we need to postmultiply. So if we want to rotate first around x and then y then our equation for global coordinate system is:
vec4 postion=Ry * Rx *Vertices
Is that correct ? Can anyone please explain this part?
[QUOTE=debonair;1265816]I have been reading some posts about rotation around the fixed axis and I have some doubts.
If we want to rotate in the global coordinate system, we need to premultiply the matrix and if we want to rotate in local coordinate system we need to postmultiply. So if we want to rotate first around x and then y then our equation for global coordinate system is:
vec4 postion=Ry * Rx *Vertices
Is that correct ? Can anyone please explain this part?[/QUOTE]
I think that’s right. the multiplication of matrix complies with associative law.
thus, vec4 postion=Ry * Rx *glVertex4f() = Ry * (Rx glVertex4f())
you can compose the R into one, = (Ry * Rx) glVertex4f() = = RglVertex4f();
you can also, Rz( Ry * (Rx *glVertex4f()) …
)
[QUOTE=debonair;1265816]
If we want to rotate in the global coordinate system, we need to premultiply the matrix and if we want to rotate in local coordinate system we need to postmultiply. [/QUOTE]
No. Not directly.
Whether you need to pre- or postmultiply matrices to vectors depends only on your matrix layout in memory: Is it column- or row-major?
You can quickly test that
vec4 position = Matrix * Vector;
is the same as //(*)
vec4 position = Vector * transpose(Matrix);
It’s interesting to see what happens if you change the ordering without transposing. That cleary give different results, but which?
Let’s take your example and change
postion=Ry * Rx * Vertices
into
postion=Vertices * Ry * Rx
With aboves rule (*) we see this is again the same as
postion=transpose( Ry * Rx ) * Vertices = transpose(Rx)*transpose(Ry)*Vertices;
So what actually get from changing premultiplication into postmultiplication with only rotationmatrices:
As you see that doesn’t have anything to do with local or global coordinate systems you want to rotate around.
What actually depends is the ordering of rotations AND translations.
If you first translate, then rotate, you will rotate around the global axes. On the other hand if you first rotate, then translate, you will rotate around the local axes.
opengl interprets vector as column major. and matrix layout is all the same.
some times matrix A x matrix B can equal to BxA
Not quite.
You’re confusing memory layout (row-major versus column-major) with transposition. While they may have the same effect in practice, they aren’t actually the same thing. In particular, matrices and vectors are mathematical constructs, and mathematics has no concept of “memory layout”.
From a mathematical perspective, (A.B)T = BT.AT. I.e. if you transpose the matrices (the transpose of a row vector is a column vector and vice versa), you need to reverse the order of any multiplications, and the result will also be transposed.
[QUOTE=reader1;1265825]opengl interprets vector as column major. and matrix layout is all the same.
[/QUOTE]
No.
It’s entirely up to the third party math library or your own classes how matrices are stored in memory.
[QUOTE=GClements;1265828]Not quite.
You’re confusing memory layout (row-major versus column-major) with transposition. While they may have the same effect in practice, they aren’t actually the same thing. In particular, matrices and vectors are mathematical constructs, and mathematics has no concept of “memory layout”.
[/QUOTE]
Yes i know.
[QUOTE=GClements;1265828]
From a mathematical perspective, (A.B)T = BT.AT. I.e. if you transpose the matrices (the transpose of a row vector is a column vector and vice versa), you need to reverse the order of any multiplications, and the result will also be transposed.[/QUOTE]
That’s exactly what i did for the rotations matrices.
Let’s have
pos = Mat * vec;
And now transpose both sides:
pos^t = (Matvec)^t = vec^tMat^t
The point i didn’t clarify in detail is, there is no need to transpose vectors in glsl. Thus what we get is just the same as in
pos = vec*Mat^t
Is there anything wrong?
[QUOTE=Betrayal;1265829]No.
It’s entirely up to the third party math library or your own classes how matrices are stored in memory.[/QUOTE]
Both microsoftware and opengl are store the matrix in same order. Merely in different way to interpret.
Just like Gc in #5 said, row or column major is a matter.
as opengl consides column major of a vector, thus it takes row arrangement of a matrix, then,
matrix x vector is normal operation.
if you take the vector as row arrangement form, you can ony use form of
vector x matrix^T, otherwise, you may get an error result.
this is very simple math.
[QUOTE=Betrayal;1265830]
That’s exactly what i did for the rotations matrices.
Let’s have
pos = Mat * vec;
And now transpose both sides:
pos^t = (Matvec)^t = vec^tMat^t
The point i didn’t clarify in detail is, there is no need to transpose vectors in glsl. Thus what we get is just the same as in
pos = vec*Mat^t
Is there anything wrong?[/QUOTE]
Look at your descriptoin, isnt it very confusing? just shown transpose, then said, no need transpose in glsl, what on earth were you expressing?
can you distinguish vector and matrix?
Thanks all for your inputs.
I think I put the question not in correct way. So I am explaining it here again. We have a object which we rotate it around X- axis now our coordinate system rotates along with that. Now if we rotate it around y- axis the rotation is not around the original y-axis but around transformed axis as our coordinate system has been rotated before. How do I fix this part?
You can think in terms of “global” or “local” coordinate system. If you are thinking in the global coordinate system, the transformations affect an object by changing its position/orientation in global coordinate system. In that case, it seems the transformation are executed in the inverse order they are defined in the code. The transformation nearest to the object-drawing affects it first. But if you think in terms of local coordinate system, then the transformations actually transforms the local coordinate system itself, and all transformations are executed in order they are defined in the code.
Long time ago, books were written well. A much better explanation than I gave you could find in the “OpenGL Programming Guide” pre-8 edition. Please read the section Viewing and Modeling Transformations in the chapter 3.
[QUOTE=debonair;1265835]Thanks all for your inputs.
I think I put the question not in correct way. So I am explaining it here again. We have a object which we rotate it around X- axis now our coordinate system rotates along with that. Now if we rotate it around y- axis the rotation is not around the original y-axis but around transformed axis as our coordinate system has been rotated before. How do I fix this part?[/QUOTE]
The matter you got, I guess, is caused by your confusion of coordinate system. this is beyond ogl,
first, you should distinguish you will aim at two coordi’tnates system, one is partial, one is global,
or say, object coordinate and world coordinate.( don’t take account of screen coordinate at present), you rotate object, you are rotating object coordinate arround the world coordinate. say, around x axis, you will get a new position, then rotating arround y axis, this y axis is also that of the world system, not your object system. it has not been changing at all. then you get a new position.
vec4 positionv = Ry * Rx * Obj. (all is in way of column vector here)
similarly, if you want rotate arround object system after rotation x axis(world), you have transform to you obj system from the world system at first. then rotate.
vec4 positionv = Robj.y * Tw * Rw.x * Obj,
where Robj.y is y axis of object system. Rw.x is that of the world. in fact, Robj.y is same as Rw.y. so you can write as (if you keep your mind fresh)
pos = Rw,y * Tw * Rw,x * Obj.
nw you will be clear.
hi debonair,
It seems to me what u r describing is a an example of hysteresis. Chen, Shoemake et. al. used the term to refer to the irritating problem of current/future states of rotations and their dependence on the previous history of states of rotation in virtual 3d space. This has been dealt with, especially in interactive 3d apps using a mouse. While many contributions have been made to solve the problem, Shoemake made the breakthrough with his neat and simple arcball in the 1990s. You could research more on the arcball/trackball concept to help, and especially if you require the interactivity, or you may just have to maintain and continually re-apply the history of all your rotations upon the object for the desired effect. Other options? I doubt it. Take a look at arcball/trackball, it’s interesting.