0

I have an object from Blender rendered into my scene and the normals are loaded correctly. I´m using Gourrad Diffuse shading passing the ModelViewProjectionMatrix (CameraToClip * ModelToCamera) to the shader and a 3x3 version of the ModelToCameraMatrix to multiply with the normals.

However, When I'm setting the output color to DiffuseColor * Angle my entire object (a cube in my case) just dissapears (not even black lines, nothing shows up on my gray background). When I replace the coloroutput to 

theColor = Vec4(1.0f, 1.0f, 1.0f, 1.0f);

it displays my obj in white without any shading. I am quite curious as to why I'm not seeing anything? Is there something wrong with my shader or with the way I pass my uniforms?

Vertex Shader:

#version 330

layout(location = 0) in vec4 position;
layout(location = 1) in vec3 normal;

smooth out vec4 theColor;

uniform mat4 modelViewProjectionMatrix;

uniform vec3 lightDir;
uniform mat3 normalModelToCameraMatrix;

void main()
{
    gl_Position = modelViewProjectionMatrix * position;

    vec3 normCamSpace = normalize(normalModelToCameraMatrix * normal);

    vec4 diffuseColor = vec4(0.6f, 0.7f, 0.8f, 1.0f);

    float angle = dot(normCamSpace, lightDir);
    angle = clamp(angle, 0, 1);

    theColor = diffuseColor  * angle;
}

Render method:

stack.Translate(glm::vec3(0.0f, 0.0f, 3.0f));

glm::vec4 lightDirCameraSpace = stack.Top() * glm::vec4(1.5f, 1.0f, 0.0f, 0.0f);
glUniform3fv(lightDirUnif, 1, glm::value_ptr(lightDirCameraSpace));
glm::mat3 normalMatrix(stack.Top());
glUniformMatrix3fv(normalModelToCameraMatrixUnif, 1, GL_FALSE, glm::value_ptr(normalMatrix));


// Draw Blender object
glBindVertexArray(this->load.vertexArrayOBject);

glm::mat4 modelViewProjectionMatrix = cameraToClipMatrix * stack.Top();
glUniformMatrix4fv(modelViewProjectionMatrixUnif, 1, GL_FALSE, glm::value_ptr(modelViewProjectionMatrix));


glDrawElements(GL_TRIANGLES, this->load.indicesVec.size(), GL_UNSIGNED_INT, 0);

I can't see what's wrong with the shader nor the rendering part.

Update When using glGetError it seems that I continuously get error code 1285 which seems to be related to "Out of Memory" problems. However, I'm not using textures of any kind so I'm kind of confused as to why this is happening?
Joey Dewd
  • 1,804
  • 3
  • 20
  • 43
  • Have you checked for errors w/ `glGetError`, and checked `GL_COMPILE_STATUS` and `GL_LINK_STATUS` of your shaders? – Tim Sep 15 '12 at 15:29
  • @Tim: Yep, I error check my shaders when I'm compiling them and no errors shows up, meaning they should've compiled succesfully. – Joey Dewd Sep 15 '12 at 16:05
  • And `glGetError`? Normally when things just 'disappear' like this you've got something broken somewhere, which will be reported by error detection. – Tim Sep 15 '12 at 16:37
  • @Tim: Compiler info says everything is compiled perfectly so no errors on the shader level. – Joey Dewd Sep 15 '12 at 17:27
  • You're not answering my question. I'm not asking about compiler info, I'm asking if you, in your program, check for the result value of `glGetError` at regular intervals, and confirm that it is always zero? – Tim Sep 15 '12 at 17:30
  • @Tim: I'm sorry, still new to OpenGl. I put a glGetError call on my rendering method and it did display an error code: 1285. Looked it up in google and it seems that's a "Out of Memory" error. I have no idea what that could come from though o.O. I guess it's somewhere in the shader since everything displays just fine when I manually add a color in the shader. – Joey Dewd Sep 15 '12 at 17:32
  • No problem, just trying to ask as clearly as I can. Can you find from which line the error message is originating? I would recommend to sprinkle glGetErrors throughout your code, and breakpoint on the first time where it asserts. – Tim Sep 15 '12 at 17:50
  • Also, you might want to just post up all your opengl code, so I can see if you've done anything obviously wrong that would generate such an error. I'm a bit puzzled myself why you would receive that. – Tim Sep 15 '12 at 17:52
  • @tim: I've localised the error to this function call : glDrawElements(GL_TRIANGLES, this->load.indicesVec.size(), GL_UNSIGNED_INT, 0); but unfortanetly doesn't help alot. This means it's somehwere in the backend of OpenGL or the shaders. – Joey Dewd Sep 15 '12 at 17:59
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/16733/discussion-between-tim-and-joey-dewd) – Tim Sep 15 '12 at 18:03
  • I would also recommend looking into the GL_ARB_debug_output extension; it gives you localized, meaningful error messages right at the point of failure. It's WAY better than the traditional glGetError()-binary-search approach. – postgoodism Sep 17 '12 at 17:45
  • @postgoodism: Thanks, I'll go and search into that extension. I find openGL hard to debug and information like this helps alot, thanks! :) – Joey Dewd Sep 18 '12 at 08:48

1 Answers1

1

My guess is that you're:

  1. enabling blending and/or alpha test
  2. multiplying your angle to the alpha channel
  3. getting a value that is not actually what you want for angle, ending with 0 for all the important angle cases

So alpha=0, the polygon is all transparent/alpha-tested.

What you should do first is make sure alpha is always 1.f, and only modulate the rgb. You could also turn off blending/alpha-test.

Then, fix the math that actually compute the angle variable as you want it.

Bahbar
  • 17,760
  • 43
  • 62
  • I haven't enabled Blending and to make sure I even disabled blending, it didn't had any effect. The alpha channel could indeed be a problem so I made a color vector where I multiplied the rgb channels with the angle and manually added the alpha channel with 1.0f and then outputted that color. Didn't work. The weird thing is however, that if my angle is 0 or -1 (meaning the math is wrong) it should at least display a 'black' cube, because if I manually insert 0 or -1 in the place of angle, it just displays a black cube. So the problem isn't in any of these points unfortanetly :(. – Joey Dewd Sep 15 '12 at 16:21
  • @JoeyDewd: yeah, I agree, it disappearing does not make much sense, hence the transparent/alpha-test theory. Oh, well. It was a guess! – Bahbar Sep 15 '12 at 16:53
  • @JoeyDewd: actually, the extra data is interesting. What happens if you try `theColor = normCamSpace;` ? – Bahbar Sep 15 '12 at 16:58
  • Hmm the following line gives me the same output, no cube: theColor = vec4(normCamSpace.x, normCamSpace.y, normCamSpace.z, 1.0f); I'm not sure how this could mean anything? :) – Joey Dewd Sep 15 '12 at 17:27
  • The normals should be fine, .obj code looks like it should and normals are correctly loaded as well. It shouldn't be a problem though cause if there's something wrong with the normals it sohuld at least display a black cube (without color) instead of nothing. It seems the real problem is an 'out of memory' issue with error code 1285. Cause is still unknown. – Joey Dewd Sep 16 '12 at 08:58