-3
\$\begingroup\$
uniform mat4 model;
uniform mat4 view;

varying vec4 vColor;

void main(){
    gl_TexCoord[0] = gl_MultiTexCoord0;
    gl_Position = view * model * gl_Vertex;

    vColor = gl_Color;

    if(view * model * gl_Vertex == model * gl_Vertex) vColor = vec4(0, 1, 0, 1);

}

Basically, if everything without the camera's view matrix applied is equal to everything WITH the camera's view matrix applied, make everything green.

Everything's green. Even when I change the view matrix (move the camera around).

Obviously, this means the view matrix is an identity one. I checked. It isn't. It's a perfectly simple 4x4 matrix, that has the 1's running diagonally and the x and y coordinates in the fourth column, first and second row respectively.

public void setMat4Uniform(Matrix4f value, String name){
    FloatBuffer buffer = BufferUtils.createFloatBuffer(4 * 4);
    value.store(buffer);
    buffer.flip();

    glUniformMatrix4(glGetUniformLocation(programId, name), false, buffer);
}

This is what I use to send uniforms to the GPU. I'm pretty sure it isn't faulty because it sends the model matrix without problems.

And here's the weird part (at least for me). If I set the gl_Position variable to just model * gl_Vertex (as opposed to view * model * gl_Vertex), and then move the camera around, nothing's green. Somehow, gl_Position = view * model * gl_Vertex is affecting my view matrix.

Could anybody help?

EDIT: I figured out what the problem was. It was a silly mistake, completely different from what I thought it was at first. Thanks, everybody, for trying to help.

\$\endgroup\$

closed as off-topic by Josh Jan 9 '14 at 19:09

  • This question does not appear to be about game development within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ I think you need to post images so people can understand the issue. 2nd Your code is hiding a lot of the openGL details. Maybe store or flip have a bug, You never know. This makes hard for other people to know your issue. \$\endgroup\$ – concept3d Jan 7 '14 at 19:08
  • \$\begingroup\$ store and flip are built-in lwjgl functionality. They don't have a bug \$\endgroup\$ – Kipras Jan 7 '14 at 19:27
  • \$\begingroup\$ Oh wow. Silly me. I forgot to clear the screen and I was moving the camera at a huge pace. So after a little push of a button everything went flying off the bounds of the screen, but because I wasn't clearing the screen it seemed as if everything stayed at one place. Stupid mistake. Sorry about that. \$\endgroup\$ – Kipras Jan 7 '14 at 19:56
  • \$\begingroup\$ You really should not be querying the location of a uniform by its string name every time you set its value. glGetUniformLocation (...) is potentially very expensive because it has to do a string comparison; implementations may optimize this to a hash map or trie, but OpenGL does not require this. The locations never change until you re-link your program, so if you store the integer location persistently and re-use that you will improve performance. \$\endgroup\$ – Andon M. Coleman Jan 8 '14 at 5:00
  • 1
    \$\begingroup\$ This question appears to be off-topic because it is about debugging your code for you. \$\endgroup\$ – Josh Jan 9 '14 at 19:09
3
\$\begingroup\$

Well, GLSL isn't doing anything weird to your view matrix.

First of all you are comparing floating point using == in your shader. This is bad, and probably will never return true, that explains why when you move the camera you never see anything grean. You are basically assuming both terms (left and right of the ==) will return the same exact value (bit by bit). Unfortunately floating point doesn't work like this, floats try to represent real world numbers (infinite) using finite precision so a lot of approximation comes into play. That's why we use error margine when comparing floats like this

if ( fabs( a - b) < 1e-12 ) // compares a and b 
instead of doing this
if ( a == b ) // this won't work if a = 0.00000091 and b = 0.00000092 
and you probably want them to be equal. (my example might not be real but you get the     
idea.

I also answered a question about floating point error here

Second, using if statements in a shader is highly discouraged, this will highly affect performance. Unlikely in your case but just for the record. Check the discussion here for using conditionals in shaders.

\$\endgroup\$
  • \$\begingroup\$ That if for turning everything to green is just for debugging. When you multiply a matrix by an identity matrix you get the exact same matrix. So basically my if checks if the view matrix is an identity matrix. Which it is, oddly, because everything gets green-shifted. Except when I dont reference the view matrix when calculating gl_Position, which is again odd. \$\endgroup\$ – Kipras Jan 7 '14 at 19:24
  • 1
    \$\begingroup\$ When you multiply a matrix by an identity matrix you get the exact same matrix that's when you have infinite precision, no when using floating points. Even after multiplying with an identity matrix your result might not be matched bit to bit. Never use == for floating points. \$\endgroup\$ – concept3d Jan 7 '14 at 19:29
  • \$\begingroup\$ Either way, that's not the point. The camera isn't moving, because the view matrix doesn't get correctly sent to GLSL, while the model matrix gets and I can't understand why THAT is happening. \$\endgroup\$ – Kipras Jan 7 '14 at 19:31
  • \$\begingroup\$ @Kipras you are assuming that, well maybe it's true. But seriously we didn't see the matrices nor how you are sending them. \$\endgroup\$ – concept3d Jan 7 '14 at 19:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.