Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 7 of 7

Thread: Lighting problem after drawing a cylinder

  1. #1
    Junior Member Newbie
    Join Date
    May 2012
    Posts
    5

    Lighting problem after drawing a cylinder

    Hi there!

    I've just started learning openGL and have a doubt that is intriguing me (I searched and read but couldn't find an answer).

    So, I created a cylinder (out of triangles), uploaded the points to a VBO and it looks fine. The problem is, when I add lighting to the scene, the top circumference looks strange. It looks like this: Cylinder top


    I believe I have calculated the vertices and normals correctly, and can't figure out what's wrong. Instead of a 'smooth' surface, I'm getting all those triangular shades. Is there an obvious reason for this to happen?

    If useful or necessary, I'll post code. Just wanted to start by knowing if there is a quick answer to the problem

    Thanks in advance!

  2. #2
    Senior Member OpenGL Pro BionicBytes's Avatar
    Join Date
    Mar 2009
    Location
    UK, London
    Posts
    1,165
    It looks like it's due to the way you have calculated the normal. If you think about it, for this shape every triangle on the top of the cyslinder would have the same normal value (eg 0,1,0). It looks like your triangles each have their own normal (not a problem so far), but each has a different value?

  3. #3
    Junior Member Newbie
    Join Date
    May 2012
    Posts
    5
    Yes, I gave each of them their own normal (probably not the best way to do it, but it's the best I know for now) in glNormalPointer, but it is indeed the same for all (0,1,0). But I'll check them again! In the meantime, can it be something else?

    Thanks


    P.S. Can it be related to the order by which I call the camera transformations and the lighting? glLightfv is currently between glLoadIdentity() and gluLookAt().
    Last edited by JayNort; 05-01-2012 at 10:18 AM. Reason: another possibility?

  4. #4
    Senior Member OpenGL Pro BionicBytes's Avatar
    Join Date
    Mar 2009
    Location
    UK, London
    Posts
    1,165
    glLightfv is currently between glLoadIdentity() and gluLookAt().
    Ah the fixed function lighting thing!
    With FF lighting the glLightv command MUST come after you have setup the camera - but BEFORE you alter the model aspect of it when drawing your models (eg glScalef, glRotatef, gltranslatef).
    So, directly after gluLookat() issue your glLightv command. This means that the light's position will now be transformed into eye space (because the ModelView matrix contains only a viewing transform - the model aspect was set to identity).

  5. #5
    Junior Member Newbie
    Join Date
    May 2012
    Posts
    5
    Thanks for explaining, I moved the glLightfv call and it's now issued directly after gluLookAt() but the problem doesn't seem to be related. I'm still stuck on it, here's an example of my cylinder drawn with only four slices (basically making it a parallelepiped) for simplicity sake, this way I was able to easily check all the created coordinates, vertices and normals. Even the side face has two completely different tones in its two triangles and each of their vertices use the same normal (0.707107, 0.0 , 0.0), which by the way is a strange value. I thought about trying to compute vertex normals instead of surface normals, but being the same plane it doesn't make any sense, does it? Sorry, I'm really at a loss here :/

  6. #6
    Senior Member OpenGL Pro BionicBytes's Avatar
    Join Date
    Mar 2009
    Location
    UK, London
    Posts
    1,165
    Have you used glScalef any where? If so your normals will not be unit length. You may need glenable (GL_RESCALE_NORMAL) to fix it.
    There are usually only 4 reasons why FF lighting does not work as expected
    1. Model winding order/bad normals
    2. glLightv command not set immediately after the camera and before any model transforms on the modelview matrix
    3. Normals have been scaled
    4. Light[n] values are bad - eg attenuation, spot light direction, etc

  7. #7
    Junior Member Newbie
    Join Date
    May 2012
    Posts
    5
    I'm not using any scaling transformations, but I guess I found the cause (number 4 in your reasons ). I was issuing glLightfv(GL_LIGHT0, GL_POSITION, lumPos) and I believe the coordinates in lumPos were messing up the whole lighting. I probably had a wrong concept about GL_POSITION =/ I'm having some trouble understanding it, but after changing lumPos[4] from {1.0,1.0,1.0,0.0} to something like {1.0,100.0,1.0,0.0} it produced a much better result. At least I think I can be sure that my normals are correclty computed along with the rest of the data.

    Well, thanks a lot BionicBytes, you've been really helpful

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •