Global uniforms cheatsheet

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.

7 Likes
@abies said: Got bit bored and created World/View/Projection matrix uniform cheatsheet

https://drive.google.com/file/d/0BwNvfRUx_gIUOUhmQkRCVFBrQ1k/edit?usp=sharing

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.

Actually theres a plugin in the SDK that should allow adding these to the code completion for frag and vert files.

2 Likes
@normen said: Actually theres a plugin in the SDK that should allow adding these to the code completion for frag and vert files.

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)

@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 :wink:

@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 :wink:

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.

Here is the cheat sheet I use in case anyone needs it:
http://hub.jmonkeyengine.org/javadoc/com/jme3/shader/UniformBinding.html

…but I don’t really need the pictures (and those were just a little confusing at first).

I’m not sure I understood your other question, though. What exactly is it that you feel is missing?

Edit: and actually, I should be honest… this is the cheat sheet I use: https://code.google.com/p/jmonkeyengine/source/browse/trunk/engine/src/core/com/jme3/shader/UniformBindingManager.java :slight_smile: The javadocs for the UniformBinding class are not so great.

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.

In the scheme of things, spot lights were added very late. It’s possible that they just weren’t handled for single pass so they stay as world space.

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

worldNormal =  (vec4(viewNormal,0)*g_ViewMatrix).xyz;

Results seem to be ok, I just want to make sure I have not missed something here.

I think that’s right… but don’t forget your 0.0 :slight_smile:

1 Like

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.

@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?

oh true didn’t read properly the end of the post.