Got bit bored and created World/View/Projection matrix uniform cheatsheet
I’ll create second page with inverse ones and 3rd page with all the rest of random things (camera, resolution, tpf etc), plus possibly a table listing all with types and proper g_ prefixed names. Pictures are taken from Coding Labs :: World, View and Projection Transformation Matrices
Before I get further, please let me know if I have not mixed up any of the terms.
Additionally, WorldMatrixInverseTranspose is WorldMatrixInverse to be used for normals? Why do we have normal 3x3 matrix only from model->view in one direction, but view->model and world->model in other direction?
Edit: Added second page with inverse transforms.
Edit: Added 3rd page with screen, camera and light uniforms and corrected one of normal matrices.
I’ll create second page with inverse ones and 3rd page with all the rest of random things (camera, resolution, tpf etc), plus possibly a table listing all with types and proper g_ prefixed names. Pictures are taken from http://www.codinglabs.net/article_world_view_projection_matrix.aspx
Before I get further, please let me know if I have not mixed up any of the terms.
Additionally, WorldMatrixInverseTranspose is WorldMatrixInverse to be used for normals? Why do we have normal 3x3 matrix only from model->view in one direction, but view->model and world->model in other direction?
Nice! I have one of these sitting around as well. Never dawned on me to actually share it >.<
EDIT: This was semi-critical when writing AO for deferred rendering.
EDIT 2: Not sure I understood your last question though. re u saying there is no matrices for these? Or they are not 3x3? (which they should be for normals). I can’t remember if I had to pass them into the shader myself or I found the globals for them… I’ll check if you need… just not sure of the exact question.
@t0neg0d said:
EDIT 2: Not sure I understood your last question though. re u saying there is no matrices for these? Or they are not 3x3? (which they should be for normals). I can't remember if I had to pass them into the shader myself or I found the globals for them... I'll check if you need... just not sure of the exact question.
There are 3 predefined matrices for normals.
NormalMatrix (model->world->view)
NormalMatrixInverse (?view->world->model?)
and
WorldMatrixInverseTranspose (?model->world?)
I was just asking why there is assymetry here and no world->model 3x3 matrix. Maybe it is just not useful in many shaders ? Or maybe there is no good name for it - would have to be named WorldMatrixInverseTransposeInverse to follow the naming scheme
@abies said:
There are 3 predefined matrices for normals.
NormalMatrix (model->world->view)
NormalMatrixInverse (?view->world->model?)
and
WorldMatrixInverseTranspose (?model->world?)
I was just asking why there is assymetry here and no world->model 3x3 matrix. Maybe it is just not useful in many shaders ? Or maybe there is no good name for it - would have to be named WorldMatrixInverseTransposeInverse to follow the naming scheme
Gotcha… isn’t WorldMatrixInverse this? This is world space to model space… which if you grab the first 3 columns of… you have what you need. Likely it’s not there because it’s just duplication of data already available.
I’m not sure if single-pass is used at all currently, but it seems to be an inconsistency between single pass and multi pass regarding LightPosition for spot lights. In multipass, it is being converted to viewspace, while in singlepass it stays in world space. Is it done on purpose?
@t0neg0d said:
I think I ended up doing this in the end (of course when I say end... I mean about the time I didn't really need it anymore)
No, I mean if somebody sat down and modified the plugin the SDK would already display these. It already does display some of these but I think theres also still some old OpenGL1 ones.
@abies said:
I'm not sure if single-pass is used at all currently, but it seems to be an inconsistency between single pass and multi pass regarding LightPosition for spot lights. In multipass, it is being converted to viewspace, while in singlepass it stays in world space. Is it done on purpose?
Complete guess here, but for the original effort towards deferred rendering, people may have been decided that worldspace was going to be how this was handled?
And I believe that single-pass isn’t being used at all atm. If I remember the answer I got when asking about how to handle single-pass lighting. If I’m wrong about this, sorry! But, I’m fairly sure I remember this being the answer.
To let me understand last parts of the game here. I need to move normals from view space to world space. There is no ready-to-use uniform for that, but basically I would need ViewMatrixInverse.inverse.transpose.toRotationMatrix. This in turn is ViewMatrix.transpose.toRotationMatrix. This means I could do, in shader
mat4 t = transpose(g_ViewMatrix);
worldNormal = (t * vec4(viewNormal,0)).xyz;
but, as I understand, matvec = vectranspose(mat), so I can just do
@nehon said:
You should compute the matrix on cpu side and send it to the shader as a mat param, It will save you an expensive computation once per pixel.
Yes, but it seems that I don’t need to do any computation after all, because I can misuse g_ViewMatrix. Unless having vec4g_ViewMatrix is a lot heavier than cpuProvidedMatrixvec3, but that shouldn’t be so bad?