Understanding Surface Normals

Understanding Surface Normals | CodeSignal Learn

Introduction

Welcome to the first lesson of our Realistic Lighting with the Phong Model course! We're embarking on an exciting journey into the world of advanced 3D graphics programming, where we'll learn to create stunning, photorealistic lighting effects. At the heart of this course is the Phong lighting model —a classic and widely used technique in computer graphics for simulating how light interacts with surfaces. The Phong Model breaks lighting down into three main components: ambient, diffuse, and specular reflection, allowing us to achieve realistic shading and highlights on 3D objects. In this opening lesson, we'll dive into one of the most fundamental concepts in computer graphics lighting: surface normals . Understanding normals is absolutely crucial because they determine how light interacts with surfaces, making them the backbone of all lighting calculations in the Phong Model. By the end of this lesson, you'll have created a rotating cube that visualizes its surface normals as beautiful rainbow colors, giving you direct insight into how these invisible mathematical vectors work.

What Are Surface Normals

(0, 0, 1)

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Vertex Data Structure with Normals

(0, 0, 1)

Vertex Shader Processing

Our vertex shader receives the position and normal data, then passes the normal information to the fragment shader for visualization. The shader uses layout qualifiers to specify exactly where each attribute comes from in our vertex buffer. glsl#version 450 core layout(location = 0) in vec3 aPos; layout(location = 1) in vec3 aNormal; uniform mat4 uModel; uniform mat4 uView; uniform mat4 uProjection; out vec3 vNormal; void main() { vNormal = aNormal; gl_Position = uProjection * uView * uModel * vec4(aPos, 1.0); }#version 450 core layout(location = 0) in vec3 aPos; layout(location = 1) in vec3 aNormal; uniform mat4 uModel; uniform mat4 uView; uniform mat4 uProjection; out vec3 vNormal; void main() { vNormal = aNormal; gl_Position = uProjection * uView * uModel * vec4(aPos, 1.0); } The vertex shader declares two input attributes: aPos at location 0 for vertex positions and aNormal at location 1 for normal vectors. We transform the position through our model-view-projection matrices as usual, but we pass the normal directly to the fragment shader without any transformation. In more advanced lighting scenarios, we would transform normals using special matrix operations, but for visualization purposes, the raw normal values work perfectly.

Fragment Shader Color Visualization

(1, 0, 0)

Vertex Attribute Configuration

To properly feed our vertex data to the shaders, we must configure OpenGL's vertex attribute pointers to match our data layout. This tells the graphics pipeline exactly how to interpret our interleaved position and normal data. C++ // Position attribute (location = 0) glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), (void *)0); glEnableVertexAttribArray(0); // Normal attribute (location = 1) glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), (void *)(3 * sizeof(float))); glEnableVertexAttribArray(1); // Position attribute (location = 0) glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), (void *)0); glEnableVertexAttribArray(0); // Normal attribute (location = 1) glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), (void *)(3 * sizeof(float))); glEnableVertexAttribArray(1); The key parameters here are the stride and offset values: we use 6 * sizeof(float) as the stride because each vertex contains 6 floats in total. For positions, the offset is 0 since they come first, while normals have an offset of 3 * sizeof(float) to skip over the position data. The GL_FALSE parameter indicates that we don't want OpenGL to normalize our values automatically, since our normals are already properly normalized.

The Local vs World Space Problem

However, as you might have noticed, we are currently choosing the color based on the normal in local space, not world space. This means the colors remain fixed to each face regardless of how the cube rotates in the world. While this is helpful for debugging and understanding the basic concept of normals, it doesn't reflect how normals behave in real lighting applications where we need to know which direction surfaces face in world coordinates. To fix this, we need to transform the local normal vector aNormal to world space using the normal matrix, which is the transpose of the inverse of the model matrix: glsl#version 450 core layout(location = 0) in vec3 aPos; layout(location = 1) in vec3 aNormal; uniform mat4 uModel; uniform mat4 uView; uniform mat4 uProjection; out vec3 vNormal; void main() { vNormal = mat3(transpose(inverse(uModel))) * aNormal; gl_Position = uProjection * uView * uModel * vec4(aPos, 1.0); }#version 450 core layout(location = 0) in vec3 aPos; layout(location = 1) in vec3 aNormal; uniform mat4 uModel; uniform mat4 uView; uniform mat4 uProjection; out vec3 vNormal; void main() { vNormal = mat3(transpose(inverse(uModel))) * aNormal; gl_Position = uProjection * uView * uModel * vec4(aPos, 1.0); } The normal transformation mat3(transpose(inverse(uModel))) * aNormal might appear complex, but it serves a vital purpose. Regular model transformations work perfectly for positions, but normals require special handling when the model matrix contains non-uniform scaling. The normal matrix ensures that our surface normals remain perpendicular to their surfaces after transformation, preserving the geometric relationships essential for accurate lighting calculations.

Now let's examine how we structure our vertex data to include both position and normal information. Each vertex in our cube contains six floating-point values: three for position coordinates and three for the normal vector.

C++

float verts[] = {
    // Front face (normal: 0, 0, 1)
    -0.5f, -0.5f,  0.5f,  0.0f,  0.0f,  1.0f, // position + normal
     0.5f, -0.5f,  0.5f,  0.0f,  0.0f,  1.0f,
     0.5f,  0.5f,  0.5f,  0.0f,  0.0f,  1.0f,
    -0.5f,  0.5f,  0.5f,  0.0f,  0.0f,  1.0f,
    // Additional faces follow...
};

Notice how we organize the data: each vertex contains its 3D position followed immediately by its normal vector. For the front face, every vertex shares the same normal $(0, 0, 1)$ because the entire face points toward positive Z. This interleaved format is memory-efficient and allows our graphics pipeline to process both position and normal data seamlessly. We define separate vertices for each face even when positions overlap, because different faces require different normals at shared corners.

The fragment shader performs the clever trick of converting normal vectors into visible colors, allowing us to see the invisible surface orientations with our eyes.

glsl

#version 450 core
in vec3 vNormal;
out vec4 FragColor;

void main() {
    // Visualize normals as colors by mapping from [-1,1] to [0,1]
    vec3 normalColor = normalize(vNormal) * 0.5 + 0.5;
    FragColor = vec4(normalColor, 1.0);
}

The magic happens in the color mapping formula: normalize(vNormal) * 0.5 + 0.5. Since normal components range from -1 to 1, multiplying by 0.5 gives us -0.5 to 0.5, then adding 0.5 shifts the range to 0 to 1, which is perfect for RGB color values. This means a normal pointing in the positive X direction $(1, 0, 0)$ becomes red $(1, 0, 0)$ , positive Y becomes green $(0, 1, 0)$ , and positive Z becomes blue $(0, 0, 1)$ . Negative directions create darker versions of these colors.