Mar 10
25

5. GLSL Per Pixel Lighting

8 Comments

Jump To:

main.cpp Source
shader.vert Source
shader.frag Source
Download

This tutorial is going to be quite simple. To achieve the effect of per pixel lighting, we simply need to move one calculation from our vertex shader to our fragment shader.

So lets go to it!

Main.CPP File:

Just for the sake of it, I have switched to a glutSolidTeapot for this tutorial. It will come on handy when testing different effects.

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114. 		    #if ( (defined(__MACH__)) && (defined(__APPLE__)) )   
#include <stdlib.h>
#include <OpenGL/gl.h>
#include <GLUT/glut.h>
#include <OpenGL/glext.h>
#else
#include <stdlib.h>
#include <GL/glew.h>
#include <GL/gl.h>
#include <GL/glut.h>
#include <GL/glext.h>
#endif

#include “shader.h”

Shader shader;

GLfloat angle = 0.0; //set the angle of rotation

//diffuse light color variables
GLfloat dlr = 1.0;
GLfloat dlg = 1.0;
GLfloat dlb = 1.0;

//ambient light color variables
GLfloat alr = 0.0;
GLfloat alg = 0.0;
GLfloat alb = 0.0;

//light position variables
GLfloat lx = 0.0;
GLfloat ly = 1.0;
GLfloat lz = 1.0;

GLfloat lw = 0.0;

void init(void) {
    glEnable(GL_DEPTH_TEST);
    glDepthFunc(GL_LESS);
    
    shader.init(“shader.vert”, “shader.frag”);
}

void cube (void) {
    glRotatef(angle, 1.0, 0.0, 0.0); //rotate on the x axis
    glRotatef(angle, 0.0, 1.0, 0.0); //rotate on the y axis
    glRotatef(angle, 0.0, 0.0, 1.0); //rotate on the z axis
    glColor4f(1.0, 0.0, 0.0, 1.0);
    glutSolidTeapot(2);
}

void setLighting(void) {
    GLfloat DiffuseLight[] = {dlr, dlg, dlb}; //set DiffuseLight[] to the 
specified values
    GLfloat AmbientLight[] = {alr, alg, alb}; //set AmbientLight[] to the 
specified values
    
    glLightfv (GL_LIGHT0, GL_DIFFUSE, DiffuseLight); //change the light
 accordingly
    glLightfv (GL_LIGHT0, GL_AMBIENT, AmbientLight); //change the light
 accordingly
    
    GLfloat LightPosition[] = {lx, ly, lz, lw}; //set the LightPosition to 
the specified values
    
    glLightfv (GL_LIGHT0, GL_POSITION, LightPosition); //change the 
light accordingly
}

void display (void) {
    glClearColor (0.0,0.0,0.0,1.0);
    glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
    glLoadIdentity();  
    gluLookAt (0.0, 0.0, 5.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0);
    
    setLighting();
    
    shader.bind();
    cube();
    shader.unbind();
    
    glutSwapBuffers();
    angle += 0.01f;
}

void reshape (int w, int h) {
    glViewport (0, 0, (GLsizei)w, (GLsizei)h);
    glMatrixMode (GL_PROJECTION);
    glLoadIdentity ();
    gluPerspective (60, (GLfloat)w / (GLfloat)h, 1.0, 100.0);
    glMatrixMode (GL_MODELVIEW);
}

int main (int argc, char **argv) {
    glutInit(&argc, argv);
    glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH); //set up
 the double buffering
    glutInitWindowSize(500, 500);
    glutInitWindowPosition(100, 100);
    glutCreateWindow(“A basic OpenGL Window“);
    
    glewInit();

    glutDisplayFunc(display);
    glutIdleFunc(display);
    
    glutReshapeFunc(reshape);
    
    init();
    
    glutMainLoop();
    
    return 0;
}

Vertex Shader Source:

In the last tutorial, to achieve lighting, we had one varying variable called diffuse_value. In this tutorial, we are going to remove this varying, and create two others. One of them is going to contain the vertex_light_position, and the other is going to contain the vertex_normal:

varying vec3 vertex_light_position;
varying vec3 vertex_normal;

Now we need to store some values in here. This is collected the exact same way as last time:

    vertex_normal = normalize(gl_NormalMatrix * gl_Normal);

    vertex_light_position = normalize(gl_LightSource[0].position.xyz);

And that’s all their is in the vertex shader. Note that I have removed the diffuse_value variable.

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16. 		    varying vec3 vertex_light_position;
varying vec3 vertex_normal;

void main() {            
    // Calculate the normal value for this vertex, in world coordinates (
multiply by gl_NormalMatrix)
    vertex_normal = normalize(gl_NormalMatrix * gl_Normal);
    // Calculate the light position for this vertex
    vertex_light_position = normalize(gl_LightSource[0].position.xyz);

    // Set the front color to the color passed through with glColor*f
    gl_FrontColor = gl_Color;
    // Set the position of the current vertex 
    gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}

 

Fragment Shader Source:

Since I changed the varying variables in the Vertex Shader, I also need to update them in the fragment shader:

varying vec3 vertex_light_position;
varying vec3 vertex_normal;

Now, if you remember the diffuse_value calculation from the previous tutorial, it has been pretty much copied and pasted into this tutorial, only now it resides inside the fragment shader:

    float diffuse_value = max(dot(vertex_normal, vertex_light_position), 0.0);

And that is all their is to it. We now have per pixel lighting. That wasn’t too hard :)

If you have any questions, please email me at swiftless@gmail.com

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

     varying vec3 vertex_light_position;
varying vec3 vertex_normal;

void main() {
    // Set the diffuse value (darkness). This is done with a dot product between
 the normal and the light
    // and the maths behind it is explained in the maths section of the site.
    float diffuse_value = max(dot(vertex_normal, vertex_light_position), 0.0);

    // Set the output color of our current pixel
    gl_FragColor = gl_Color * diffuse_value;
}

 

Download:

Download shader.h Source Code for this Tutorial

Download shader.cpp Source Code for this Tutorial

Download main.cpp Source Code for this Tutorial

Download shader.vert Source Code for this Tutorial

Download shader.frag Source Code for this Tutorial

Related posts:

  1. 4. GLSL Lighting
  2. 6. GLSL Materials
  3. 3. GLSL Coloring
  4. 2. GLSL Validation
  5. 7. Texturing in GLSL

8 Responses to "5. GLSL Per Pixel Lighting"

  • Nick says:
    November 10, 2011 at 9:04 am
    Reply

    I can’t figure out how to add specular light to the pixel shader.
    When I do, it comes out per-vertex, not per-pixel…

  • DUdeson says:
    October 26, 2011 at 5:33 am
    Reply

    Wtf?!
    Using the light position is like 10x easier than the direction!!!!

  • Paras says:
    May 19, 2011 at 9:03 pm
    Reply

    Might be this is a real noob question,

    I have followed the 5 GLSL tutes uptill now, but I am unable to understand that, how have we achieved per pixel/ vertex effects, I mean we have called our shader program inside the ‘display’ function and this will update per frame. Thus the code in shader program will affect each and every pixel/vertex in same way. How have we achieved control on each vertex/pixel?
    How can we in same run, say change color of few pixels to red and few white depending on their z values?

    • Swiftless says:
      May 20, 2011 at 12:00 pm
      Reply

      Hi Paras,

      If you would like to do something like that, the vertex shader allows you to read the z-values of vertices. You can then set up a variable which is sent from the vertex shader to the fragment shader, and the fragment shader can use this variable to decide on whether or not to change the colour of the current pixels.

      It might be important to note that pixel values are interpolated between vertices. So if one vertex has a z-value of -10 and we tell the pixels for that vertex to be red, and the next vertex has a z-value of -20 (both for the same geometry), and we tell the pixels for that vertex to be green, then we will see a smoothing between red and green.

      While we have full control over our pixels, we can’t access them straight on an x,y basis and say, I want this pixel at this location, to be this. The pixel shader is applied to geometry, and the pixels created by the geometry are what are manipulated.

      Cheers,
      Swiftless

  • Alfonse says:
    November 29, 2010 at 4:39 am
    Reply

    Why do you call it “vertex_light_position”, when it is very clearly a light *direction*? You normalize it, you dot it with the surface normal. It’s a direction, not a position.

    Also, there’s no reason to pass it as a varying, since it doesn’t change. It’s just the light direction accessed from the OpenGL variables. Which the fragment shader can access just as well as the vertex shader.

    • Swiftless says:
      December 6, 2010 at 8:46 am
      Reply

      Hey Alfonse,

      While your comments have a point, I call it vertex_light_position because OpenGL refers to it as light position. Also, it depends on the type of light, if you have a point light, it has a position and no direction while a directional light is opposite and has a direction but no position.

      As for varying variables, it is not always optimal to do all your lighting calculations in the fragment shader this lets us offload some parts to the vertex shader. This also saves us reading the variable every pixel from OpenGL, we can read it per vertex which can save quite a few fetches.

      Thanks,
      Swiftless

      • Alfonse says:
        March 5, 2011 at 2:31 pm
        Reply

        Yes, OpenGL’s default lighting variables do call it a “position” even for directional lights. But that doesn’t mean that you need to do so. This is, after all, a tutorial; a way to make things clearer to the user. Treating a position like a direction does not help make things clearer.

        As for the cost of reading uniforms in a fragment shader, that simply doesn’t exist. Reading uniforms costs just as much as reading varyings.

        Also, passing varyings has a very real cost associated with it. It makes the per-output vertex data bigger, which means that per-output vertex data takes up more room in the post-T&L cache. Which means you can have fewer vertices in the post T&L cache. Which slows things down.

        The cost of reading a uniform doesn’t compare to the cost of an additional varying.

        • Swiftless says:
          March 6, 2011 at 12:41 pm
          Reply

          Hi Alfonse,

          I see what you mean, but I stick by my position it call it position to keep the transition simple from the fixed function mode. But I should explain this better when I do a rewrite of the tutorial eventually. I’m pretty sure I explain it on the OpenGL Tips page, but that is a bit of a round-about trip. Also, it’s not the fact that it’s dotted and normalized that makes it a direction. You do the same calculations for a position light (It shoots out in all directions). It’s just a minor change in the rest of your code to switch from positional to directional in appearance.

          I’m not sure you understand what I meant in regard to the number of variable fetches.

          “As for varying variables, it is not always optimal to do all your lighting calculations in the fragment shader this lets us offload some parts to the vertex shader.”

          For example, you do the dot product calculation. If you do it per-vertex, you may have 1000 vertices and this means 1000 dot product calculations, as opposed to possibly 1000×1000 calculations if you do it on a per-pixel basis. Yes, there is a difference in quality, this is per-vertex lighting compared to per-pixel lighting, but it’s a valid example of the speed difference.

          “This also saves us reading the variable every pixel from OpenGL, we can read it per vertex which can save quite a few fetches. ”

          Take bump mapping vs displacement mapping. Either way you have a texture read. But in the vertex shader, you only have one texture fetch per vertex, as opposed to a texture fetch every pixel.

          These examples are more on the extreme differences side, but it shows the point I am trying to make clearly.

          Just a note on what you mentioned. Uniforms vs Varyings in regard to speed. Uniforms are passed from system memory to GPU memory, this has a MUCH higher cost associated with it compared to a varying variable which is created on the GPU and requires no passing around in memory.

          I’d like to know where the information is coming from that the more varying variables you have, the less vertices you can have. Vertex output relies on the hardware capability, not the amount of varying variables you have. Imagine the kind of trouble geometry shaders and tesselation engines would run into if that was the case, where you can effectively output several times the number of incoming vertices.

          Cheers,
          Swiftless

Leave a Comment