inverse and transpose of matrices in glSlang state

thread in the suggestions forum: http://www.opengl.org/discussion_boards/ubb/Forum7/HTML/000453.html

i would like to know your opinion.

thx

I agree… some of the states offered by ARB_vp are quite useful, like state.matrix.modelview[0].invtrans.row[3], which I use to implicitly extract the objectspace camerasposition. I actually miss it in GLSL :frowning:
Also, ARB_vp offered a program environment where you could store data that is shared by all vertex programs. There´s no such thing in GLSL, though :frowning:
Finally I dislike that it is not possible to refer to a single row in a matrix. I really think, its more useful to have access to the rows of a matrix than its columns. I´d also like to see built-in functionality that allows me to use:
“attribute mat3 tangentspace;”
but provide the ROWS for this matrix with the bound generic attribute streams.

From the docs, you should be able to access rows and columns, but I just tested it on my machine, but it gives a compilation error.

mat3 m;
m.00 = 1; // set the first element to 1.

m.0_ = vec3 (1, 2, 3); // sets the first row to 1, 2, 3 .

m._0 = vec3 (1, 2, 3); //sets the first column to 1, 2, 3 .

V-man, you are looking at an old specification.

mat4 foo;
column1 = foo[0];
row1 = vec4( foo[0][0], foo[1][0], foo[2][0], foo[3][0] );

-mr. bill

[This message has been edited by mrbill (edited 03-07-2004).]

[This message has been edited by mrbill (edited 03-07-2004).]

row1 = vec4( foo[0][0], foo[1][0], foo[2][0], foo[3][0] );

smells like a very slow solution to me. I don´t know if the compiler catches the “idea” of what you´re trying to do here and is able to optimize it.

Originally posted by skynet:
[quote]row1 = vec4( foo[0][0], foo[1][0], foo[2][0], foo[3][0] );
smells like a very slow solution to me. I don´t know if the compiler catches the “idea” of what you´re trying to do here and is able to optimize it.
[/QUOTE]Note that if a matrix really is stored in column major order (encouraged by the way OGL specs are written), then a matrix row really is 4 scattered floats. So, there is some connection between the ease of extracting a row vs. column and what’s likely happening beneath the scene.

However, in the end, this is implementation dependent, and the langauge would benefit from addition of more matrix extraction and manipulation tools.

JohnK

Something like this:

inv_trans_mat = transpose( inverse( mat ) );

should be straightforward to support if it is a purely a function of uniform variable(s).

It could (and arguably should) be supported “for free” via constant folding at some point in the future.

Nice idea, cass! Pure virtualisation :slight_smile: I like it.
If you will implement it, i will use it :wink:

Originally posted by Zengar:
Nice idea, cass! Pure virtualisation :slight_smile: I like it.
If you will implement it, i will use it :wink:

Trust me, if developers write lots of expressions of uniforms, drivers will have to recognize them and supply them.

Recomputing uniform expressions at every vertex or fragment is just not an option.

Cass

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.