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

Before we dive into code, let's build a solid understanding of what surface normals actually represent. A surface normal is a vector that points perpendicular to a surface at any given point. Think of it as an invisible arrow sticking straight out from the surface, indicating which direction the surface is "facing." When light hits a surface, the angle between the light direction and the surface normal determines how bright that surface appears. This is why a wall facing directly toward a light source appears brighter than one facing away from it. In computer graphics, we represent these normals as three-dimensional vectors with x, y, and z components, where each component ranges from -1 to 1 after normalization.

In our 3D coordinate system, surface normals are typically unit vectors, meaning they have a length of exactly 1.0. For a cube, each face has a distinct normal vector: the front face points toward positive Z with normal $(0, 0, 1)$ , the back face toward negative Z with normal $(0, 0, -1)$ , and so on. The mathematical beauty of normals lies in their consistency; regardless of where on a flat surface we sample, the normal remains the same. However, for curved surfaces like spheres, the normal changes at every point, always pointing directly away from the center. This mathematical precision allows graphics hardware to perform lighting calculations with incredible efficiency and accuracy.

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.