Lighting issues in OpenGL

Question

I have a triangle mesh that has no texture, but a set color ( sort of blue ) and alpha ( 0.7f ). This mesh is run time generated and the normals are correct. I find that with lighting on, the color of my object changes as it moves around the level. Also, the lighting doesn't look right. When i draw this object, this is the code:

glEnable( GL_COLOR_MATERIAL );
float matColor[] = { cur->GetRed(), cur->GetGreen(), cur->GetBlue(), cur->GetAlpha() };
float white[] = { 0.3f, 0.3f, 0.3f, 1.0f };
glMaterialfv(GL_FRONT_AND_BACK, GL_DIFFUSE, matColor);
glMaterialfv(GL_FRONT_AND_BACK, GL_SPECULAR, white);

Another odd thing i noticed is that the lighting fails when i disable GL_FRONT_AND_BACK and use just GL_FRONT or GL_BACK. Here is my lighting set up ( done once at beginning of renderer ):

m_lightAmbient[] = { 0.2f, 0.2f, 0.2f, 1.0f };
m_lightSpecular[] = { 1.0f, 1.0f, 1.0f, 1.0f };
m_lightPosition[] = { 0.0f, 1200.0f, 0.0f, 1.0f };

glLightfv(GL_LIGHT0, GL_AMBIENT, m_lightAmbient);
glLightfv(GL_LIGHT0, GL_SPECULAR, m_lightSpecular);
glLightfv(GL_LIGHT0, GL_POSITION, m_lightPosition);

EDIT: I've done a lot to make the normals "more" correct ( since i'm generating the surface myself ), but the objects color still changes depending where it is. Why is this? Does openGL have some special environment blending i don't know about? EDIT: Turns out the color changing was because a previous texture was on the texture stack, and even though it wasn't being drawn, glMaterialfv was blending with it.

Answer 1

If your lighting fails when GL_FRONT_AND_BACK is disabled it's possible that your normals are flipped.

Answer 2

If your triangles are alpha-blended, won't you have to sort your faces by z-order from the camera? Otherwise you could be rendering a face at the back of the object on top of a face at the front.

Answer 3

Could you post the code that initializes OpenGL? You're saying that all other meshes are drawn perfectly? Are you rendering them simultanously?

Answer 4

@sebastion: multiple draw calls, each object gets a glDrawArrays. some are textured, some colored, all with normals. gl init code is: glMatrixMode(GL_MODELVIEW);

// Vertices!
glEnableClientState(GL_VERTEX_ARRAY);

// Depth func
glEnable(GL_DEPTH_TEST);
glDepthFunc( GL_LESS );

// Enable alpha blending
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

// Lighting
glEnable(GL_LIGHTING);
glEnable(GL_LIGHT0);
glLightfv(GL_LIGHT0, GL_AMBIENT, m_lightAmbient);
glLightfv(GL_LIGHT0, GL_SPECULAR, m_lightSpecular);
glLightfv(GL_LIGHT0, GL_POSITION, m_lightPosition);

// Culling
glDisable( GL_CULL_FACE );
// Smooth Shading
glShadeModel(GL_SMOOTH);

m_glSetupDone = true;

after this i have some camera set up, but thats completely standard, projection mode, frustum, modelview, look at, translate.

Answer 5

@response to stusmith:

Z-testing won't help you with transparent triangles, you'll need per-triangle alpha sorting too. If you have an object that at any time could have overlapping triangles facing the camera (a concave object) you must draw the farthest triangles first to ensure blending is performed correctly, since Z-testing doesn't take transparency into account. Consider these two overlapping (and transparent) triangles and think about what happens when that little overlapped region is drawn, with or without Z-testing. You'll probably reach the conclusion that the drawing order does, in fact, matter. Transparency sucks :P

    /\    /\
   /  \  /  \
  /    \/    \
 /     /\     \
/_____/__\_____\

I'm not convinced that this is your problem, but alpha sorting is something you need to take into account when dealing with partly transparent objects.

Answer 6

Are you sure your normals are normalized? If not and you are specifying normals via glNormal calls, you could try to let OpenGL do the normalization for you, keep in mind that this should be avoided, but you can test it out:

glEnable(GL_NORMALIZE);

This way you are telling OpenGL to rescale all the normal vectors supplied via glNormal.