thread in the suggestions forum: http://www.opengl.org/discussion_boa...ML/000453.html
i would like to know your opinion.
thx
thread in the suggestions forum: http://www.opengl.org/discussion_boa...ML/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 :-(
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 :-(
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 .
--------------------
------------------------------
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
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).]
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.row1 = vec4( foo[0][0], foo[1][0], foo[2][0], foo[3][0] );
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.Originally posted by skynet:
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.row1 = vec4( foo[0][0], foo[1][0], foo[2][0], foo[3][0] );
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.
Cass Everitt -- cass@xyzw.us
Nice idea, cass! Pure virtualisationI like it.
If you will implement it, i will use it![]()
Trust me, if developers write lots of expressions of uniforms, drivers will have to recognize them and supply them.Originally posted by Zengar:
Nice idea, cass! Pure virtualisationI like it.
If you will implement it, i will use it![]()
Recomputing uniform expressions at every vertex or fragment is just not an option.
Cass
Cass Everitt -- cass@xyzw.us