Order of linear algebra in GLSL

[Descenterace]

DirectX had a funny way of dealing with this. I wonder if OGL is the same...

Are vectors in OGL and GLSL column or row vectors?

For instance, usually:

/ 1 2 0 2 \ / 1 \ / 1*1 + 2*2 + 4*0 + 3*2 \
| 3 0 1 3 | | 2 | = | 1*3 + 2*0 + 4*1 + 3*3 |
| 5 6 1 0 | | 4 | | 1*5 + 2*6 + 4*1 + 3*0 |
\ 1 0 0 2 / \ 3 / \ 1*1 + 2*0 + 4*0 + 3*2 /

but if GLSL is treating vectors as row vectors then most of the short cuts I've prepared suddenly go out the window. DX used column vectors in C++ and row vectors in shaders, so it was necessary to pass the inverse transpose model-view-projection matrix to the shader. I really hope OGL doesn't do anything similar.

If I multiply a vector by a matrix, will GLSL treat it as the same operation as multiplying a matrix by a vector? Or does it not care about premultiplication and postmultiplication?

[Corrail]

In GLSL you can use both:

gl_Position = gl_Vertex * gl_ModelViewProjectionMatrix;

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;

In the first example gl_Vertex is threated as a row vector. In the second example gl_Vertex is a row vector.

But because OGL uses row vectors the second example is quite faster!

[Relic]

You got a typo in the second sentence and the last statement is completely wrong.

matrix * vector in math terminology is multiplying row * column, means vector is a column vector as all vectors in OpenGL.
Matrices are downloaded in column-major order which makes OpenGL different from C notations.
The performance should be the same because you need four instructions for both of the above calculations.

[Corrail]

You got a typo in the second sentence and the last statement is completely wrong.

Damn... *knockmyheadonthetable*
Thanks a lot for correcting me!

[Descenterace]

Thanks for clarifying. I've done a few expansions on paper too and it's becoming a lot clearer now.

How much overhead is associated with switching Shaders? My skysphere renderer is using one Shader for sky, one for planets, and one for planet rings. Will switching between these (as little as possible, mind you) incur a great deal of overhead and, more importantly, do I have to set up Projection and Camera matrices again after changing Shaders?

[V-man]

If I multiply a vector by a matrix, will GLSL treat it as the same operation as multiplying a matrix by a vector? Or does it not care about premultiplication and postmultiplication?

Just to be clear

vector * matrix != matrix * vector

If this is the case with D3D, then it's broken.

For transforming the vertex into clipspace, you do
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;

There is some significant overhead. If you can avoid redundent switches by reordering how you render, it would be better.

Projection and Modelview (Camera?) are uniforms and they belong to the state engine.
They don't change unless you change them.
Changing shaders or anything else doesn't change them.

[Descenterace]

I don't think D3D Shaders let you choose which order you multiply in anyway. I haven't used the DirectX HLSL. DX Shader Assembly has an m4x4 instruction, which only allows you to multiply vector * matrix. And this has just answered my eternal question: why do DirectX Shaders need the Inverse Transpose Model-View-Projection matrix...

Answer: DirectX Shader handling is broken.

[Corrail]

Originally posted by Descenterace:
...why do DirectX Shaders need the Inverse Transpose Model-View-Projection matrix...

Because tranforming normals can cause problems if you multiply a normal with the Model-View Matrix:
For example take the matrix:

(1 0 0 0)
(0 2 0 0)
(0 0 2 0)
(0 0 0 1)

if you multiply a normal with that matrix the normal isn't correct transformed. The inverse-transpose Model-View Matrix handels that (this matrix is also call normal matrix in GLSL).

[V-man]

"m4x4 instruction"

They can always change the compiler so that it handles both cases. The problem is that you would need the transpose.

matrix * vector == vector * (matrix)^T

"Inverse Transpose Model-View-Projection"

This is for transforming vertices? No, they do use the mvp.

One strange thing I noticed about D3D shaders is that some people were transforming the normal with the modelview matrix and it seemed to work. I'm not sure what the explanation for that is either.

Anyway, in this forum, we pour whiskey, not orange juice.

If you want to transform your normal in GL,

//ARBvp
DP3 result.x, state.matrix.modelview.invtrans[0], normal;
DP3 result.y, state.matrix.modelview.invtrans[1], normal;
DP3 result.z, state.matrix.modelview.invtrans[2], normal;

//GLSL
result = gl_NormalMatrix * gl_Normal;

[Corrail]

One strange thing I noticed about D3D shaders is that some people were transforming the normal with the modelview matrix and it seemed to work. I'm not sure what the explanation for that is either.

If you only use rigid body transformations (rotation and translation) than the inverse transpose model-view matrix is equal to the model view matrix:

((MV)^T)^(-1) = MV

This is only the case if you use tranformation where the elementar tranformation matrix has this property ( ((M)^T)^(-1) = M ). As said, this is true for rotation and translation matrices.