Shading with Surface Normals

Introduction: From Flat to Three-Dimensional

In the previous lesson, you successfully rendered your first 3D object — a sphere — using ray tracing. However, if you look closely at the result, you'll notice something that might seem a bit disappointing: the sphere appears as a flat red circle. There's no sense of depth, no curvature, no indication that you're looking at a three-dimensional object rather than a simple 2D disk painted on the screen. This flatness occurs because you're coloring every pixel that hits the sphere with the exact same solid red color, regardless of where on the sphere's surface that ray intersects. In the real world, objects appear three-dimensional because light interacts differently with different parts of their surfaces depending on the surface orientation. A sphere's surface curves away from us, and this curvature should be visible in how it's shaded. In this lesson, you'll learn how to give your sphere a sense of depth and dimensionality by using surface normals . By the end of this lesson, your flat red circle will transform into a sphere that clearly looks three-dimensional, with color gradients that reveal its curved surface. You'll accomplish this by computing the surface normal at each intersection point and mapping that normal vector directly to RGB color values. While this isn't yet realistic lighting (that comes later), it's a crucial stepping stone that will help you understand how surface orientation affects appearance and prepare you for implementing proper lighting models. The mathematics involved are straightforward, and you'll see that with just a few modifications to your existing code, you can achieve dramatically more convincing results. Let's begin by understanding what surface normals are and why they're so important in computer graphics.

Understanding Surface Normals

Join the 1M+ learners on CodeSignal

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

Modifying `hit_sphere()` to Return More Information

Our current hit_sphere() function has a limitation that prevents us from easily computing surface normals. As you'll recall from the previous lesson, the function returns a single double value: the parameter t where the ray hits the sphere, or -1.0 if there's no hit. This works fine for simply detecting whether a hit occurred, but to compute the surface normal, we need to know the exact value of t so we can calculate the hit point using r.at(t).

The problem is that once hit_sphere() returns, we've lost access to that t value in our ray_color() function. We could call hit_sphere() twice — once to check if there's a hit, and again to get the t value — but that would be inefficient and inelegant. Instead, we'll use a common pattern in C++ programming: we'll change the function to return a bool indicating whether a hit occurred, and pass the t value back through a reference parameter.

A reference parameter allows a function to modify a variable that belongs to the caller. When we declare a parameter with an ampersand (&), like double& t_hit, we're saying that instead of receiving a copy of the value, the function receives a reference to the original variable. Any changes the function makes to t_hit will be reflected in the caller's variable. This pattern is extremely common in ray tracing code because intersection functions often need to return multiple pieces of information: whether a hit occurred, where it occurred, and potentially other data like the surface normal or material properties.

Here's our updated hit_sphere() function:

C++

bool hit_sphere(const point3& center, double radius, const ray& r, double& t_hit) {
    vec3 oc = r.origin() - center;
    auto a = dot(r.direction(), r.direction());
    auto half_b = dot(oc, r.direction());
    auto c = dot(oc, oc) - radius*radius;
    auto disc = half_b*half_b - a*c;
    if (disc < 0) return false;
    t_hit = (-half_b - std::sqrt(disc)) / a;
    if (t_hit <= 0) {
        t_hit = (-half_b + std::sqrt(disc)) / a;
        if (t_hit <= 0) return false;
    }
    return true;
}

bool hit_sphere(const point3& center, double radius, const ray& r, double& t_hit) {
    vec3 oc = r.origin() - center;
    auto a = dot(r.direction(), r.direction());
    auto half_b = dot(oc, r.direction());
    auto c = dot(oc, oc) - radius*radius;
    auto disc = half_b*half_b - a*c;
    if (disc < 0) return false;
    t_hit = (-half_b - std::sqrt(disc)) / a;
    if (t_hit <= 0) {
        t_hit = (-half_b + std::sqrt(disc)) / a;
        if (t_hit <= 0) return false;
    }
    return true;
}

Notice the changes from our previous version. The return type is now bool instead of double, and we've added a fourth parameter double& t_hit that will receive the intersection distance. The core mathematics remain identical — we still compute the same quadratic coefficients and discriminant. However, instead of returning -1.0 when there's no intersection, we return false. When there is an intersection, we store the t value in t_hit and return true.

There's one additional improvement in this version: we now check whether t_hit is positive before accepting it. Remember that t represents how far along the ray we travel from the origin. A negative t would mean the intersection point is behind the ray's origin, which shouldn't be visible. If the first solution (the nearer intersection) is negative or zero, we try the second solution (the farther intersection). If both are non-positive, we return false because the sphere is entirely behind the camera.

This pattern of returning a boolean success indicator while passing back additional data through reference parameters is something you'll see frequently in ray tracing code. It's clean, efficient, and makes the calling code easy to read and understand.

Computing the Hit Point and Surface Normal

Now that our hit_sphere() function can tell us both whether a hit occurred and where it occurred (via the t value), we can compute the actual 3D point where the ray intersected the sphere's surface. This hit point is essential because it's what we need to calculate the surface normal.

Computing the hit point is straightforward using our ray's at() method. Remember that a ray is defined parametrically as r(t) = o + td, where o is the origin and d is the direction. Our ray class provides the at(t) method that implements exactly this calculation. So if hit_sphere() tells us that the ray hits the sphere at parameter value t, we can find the hit point with point3 p = r.at(t).

Once we have the hit point, calculating the outward surface normal is equally simple. As we discussed earlier, for a sphere centered at c, the normal at point p is the unit vector pointing from c to p. In code, this becomes vec3 N = unit_vector(p - center). The subtraction p - center gives us a vector pointing from the sphere's center to the hit point, and unit_vector() normalizes it to length 1.

Why do we use unit_vector() here? While we could work with the unnormalized vector p - center, keeping normals at unit length is a standard convention in computer graphics. Unit-length normals simplify many calculations, particularly when we implement lighting models in future lessons. For our current purpose of visualizing normals as colors, using unit vectors ensures that the color mapping we're about to implement produces consistent, predictable results. A unit vector's components always range from -1 to 1, which makes the transformation to RGB values straightforward.

Let's see how this looks in the context of our ray_color() function. We'll call hit_sphere() with our reference parameter, and if it returns true, we'll compute both the hit point and the normal:

C++

double t;
point3 center(0,0,-1);
double radius = 0.5;
if (hit_sphere(center, radius, r, t)) {
    point3 p = r.at(t);
    vec3 N = unit_vector(p - center);
    // We'll use N to determine the color (next section)
}

double t;
point3 center(0,0,-1);
double radius = 0.5;
if (hit_sphere(center, radius, r, t)) {
    point3 p = r.at(t);
    vec3 N = unit_vector(p - center);
    // We'll use N to determine the color (next section)
}

The variable t is declared before the if statement so that hit_sphere() can modify it through the reference parameter. If the function returns true, we know that t contains a valid intersection distance, so we compute the hit point p and then the normal N. These two lines of code — r.at(t) and unit_vector(p - center) — do all the geometric work needed to understand the sphere's surface orientation at the intersection point.

Mapping Normal Vectors to RGB Colors

Now comes the interesting part: how do we visualize these surface normals? The technique we'll use is to map the normal vector's components directly to RGB color values. This creates a color-coded visualization where different surface orientations produce different colors, immediately revealing the sphere's three-dimensional structure.

The challenge is that normal vector components range from -1 to 1 (since we're using unit vectors), but RGB color channels need values in the range 0 to 1 (which our write_color() function then scales to 0-255 for the PPM format). We need a transformation that maps the range [-1, 1] to [0, 1]. The mathematical transformation we'll use is: color_component = 0.5 * (normal_component + 1). Let's understand why this works. Adding 1 to a value in the range [-1, 1] gives us a value in the range [0, 2]. Multiplying by 0.5 then scales this to [0, 1], which is exactly what we need.

We apply this transformation to all three components of the normal vector simultaneously. If our normal is N = (Nx, Ny, Nz), our color becomes: color = 0.5 * (N + 1) = 0.5 * (Nx + 1, Ny + 1, Nz + 1). In our code, we can write this concisely as 0.5*color(N.x()+1, N.y()+1, N.z()+1), where we're using our color type (which is just a vec3) and taking advantage of scalar multiplication.

What does this mapping mean visually? The X component of the normal maps to the red channel, the Y component to green, and the Z component to blue. Consider what this means for different points on the sphere. At the rightmost visible point of the sphere, the normal points in the positive X direction, so Nx is close to 1, giving us a strong red component. At the topmost point, the normal points in the positive Y direction, producing a strong green component. At the point closest to the camera, the normal points in the positive Z direction (toward us), creating a strong blue component.

Points where the normal has negative components will have reduced color intensity in the corresponding channels. For example, at the leftmost visible point, Nx is close to -1, which maps to a red value near 0 (dark). The result is a sphere with a beautiful gradient of colors that clearly shows how the surface curves in three-dimensional space. The center of the sphere (the point facing directly toward the camera) will appear bluish because the Z component dominates, while the edges will show reds, greens, and various combinations depending on their orientation.

This color-coding technique is more than just a pretty visualization — it's a powerful debugging tool that you'll use throughout your ray tracing journey. When you're implementing complex geometry or lighting calculations, being able to see the normals as colors helps you quickly verify that your calculations are correct. If the colors look wrong or discontinuous, you know something is amiss with your normal calculations.

The Complete Implementation

Let's now put all the pieces together and see the complete updated code. Here's the full ray_color() function with our normal-based shading:

C++

color ray_color(const ray& r) {
    double t;
    point3 center(0,0,-1);
    double radius = 0.5;
    if (hit_sphere(center, radius, r, t)) {
        point3 p = r.at(t);
        vec3 N = unit_vector(p - center);
        return 0.5*color(N.x()+1, N.y()+1, N.z()+1);
    }
    vec3 unit_dir = unit_vector(r.direction());
    double k = 0.5 * (unit_dir.y() + 1.0);
    return (1.0 - k)*color(1,1,1) + k*color(0.5,0.7,1.0);
}

color ray_color(const ray& r) {
    double t;
    point3 center(0,0,-1);
    double radius = 0.5;
    if (hit_sphere(center, radius, r, t)) {
        point3 p = r.at(t);
        vec3 N = unit_vector(p - center);
        return 0.5*color(N.x()+1, N.y()+1, N.z()+1);
    }
    vec3 unit_dir = unit_vector(r.direction());
    double k = 0.5 * (unit_dir.y() + 1.0);
    return (1.0 - k)*color(1,1,1) + k*color(0.5,0.7,1.0);
}

Let's walk through the complete flow from ray to colored pixel. For each pixel in our image, we construct a ray from the camera through that pixel. We then call ray_color() with this ray. Inside ray_color(), we first attempt to intersect the ray with our sphere by calling hit_sphere(). We pass a reference to the variable t, which will receive the intersection distance if a hit occurs.

If hit_sphere() returns true, we know the ray hit the sphere, and t contains the distance to the hit point. We compute the actual 3D hit point using r.at(t), which evaluates the ray equation at parameter t. With the hit point in hand, we calculate the outward surface normal by subtracting the sphere's center from the hit point and normalizing the result. This normal vector tells us which direction the sphere's surface is facing at this particular intersection point.

We then transform this normal into a color by applying our mapping formula: we add 1 to each component (shifting the range from [-1,1] to [0,2]) and multiply by 0.5 (scaling to [0,1]). This gives us an RGB color where the red channel represents the X component of the normal, green represents Y, and blue represents Z. We return this color, which will be written to the corresponding pixel in our output image.

If the ray doesn't hit the sphere, we fall through to the background gradient code, which remains unchanged from the previous lesson. This creates the familiar blue-to-white gradient that makes our sphere stand out clearly against the background.

The complete main() function remains essentially the same as before:

C++

int main() {
    const double aspect_ratio = 16.0/9.0;
    const int image_width = 400;
    const int image_height = static_cast<int>(image_width / aspect_ratio);

    std::ofstream out("ppm/image.ppm");
    out << "P3\n" << image_width << ' ' << image_height << "\n255\n";

    auto viewport_height = 2.0;
    auto viewport_width  = aspect_ratio * viewport_height;
    auto focal_length    = 1.0;

    point3 origin(0,0,0);
    vec3 horizontal(viewport_width,0,0);
    vec3 vertical(0,viewport_height,0);
    point3 lower_left = origin - horizontal/2 - vertical/2 - vec3(0,0,focal_length);

    for (int j = image_height-1; j >= 0; --j) {
        std::cerr << "\rScanlines remaining: " << j << ' ' << std::flush;
        for (int i=0;i<image_width;++i) {
            double u = double(i) / (image_width-1);
            double v = double(j) / (image_height-1);
            ray r(origin, lower_left + u*horizontal + v*vertical - origin);
            write_color(out, ray_color(r));
        }
    }
    std::cerr << "\nDone.                 \n";
}

int main() {
    const double aspect_ratio = 16.0/9.0;
    const int image_width = 400;
    const int image_height = static_cast<int>(image_width / aspect_ratio);

    std::ofstream out("ppm/image.ppm");
    out << "P3\n" << image_width << ' ' << image_height << "\n255\n";

    auto viewport_height = 2.0;
    auto viewport_width  = aspect_ratio * viewport_height;
    auto focal_length    = 1.0;

    point3 origin(0,0,0);
    vec3 horizontal(viewport_width,0,0);
    vec3 vertical(0,viewport_height,0);
    point3 lower_left = origin - horizontal/2 - vertical/2 - vec3(0,0,focal_length);

    for (int j = image_height-1; j >= 0; --j) {
        std::cerr << "\rScanlines remaining: " << j << ' ' << std::flush;
        for (int i=0;i<image_width;++i) {
            double u = double(i) / (image_width-1);
            double v = double(j) / (image_height-1);
            ray r(origin, lower_left + u*horizontal + v*vertical - origin);
            write_color(out, ray_color(r));
        }
    }
    std::cerr << "\nDone.                 \n";
}

When you compile and run this program, you'll see the familiar progress output in your terminal:

Scanlines remaining: 224 
Scanlines remaining: 223 
...
Scanlines remaining: 1 
Scanlines remaining: 0 
Done.

Scanlines remaining: 224 
Scanlines remaining: 223 
...
Scanlines remaining: 1 
Scanlines remaining: 0 
Done.

But when you open the resulting image.ppm file, you'll see something dramatically different from the flat red circle of the previous lesson. Instead, you'll see a sphere with a smooth gradient of colors that clearly reveals its three-dimensional curved surface. The transformation from flat to three-dimensional is immediate and striking.

Understanding Your Results and What's Next

When you examine your rendered image, take a moment to really look at the colors and understand what they're telling you about the sphere's geometry. The center of the sphere, where the surface faces directly toward the camera, should appear predominantly blue or cyan. This makes sense because at that point, the surface normal points in the positive Z direction (toward you), and the Z component maps to the blue channel.

As you move toward the edges of the sphere, you'll see the colors shift. The right edge will show more red because the normals there point in the positive X direction. The top edge will show more green because those normals point in the positive Y direction. The left and bottom edges will be darker because the normals there have negative X and Y components, respectively, which map to lower color values. The smooth gradients between these regions reveal how the sphere's surface continuously curves in three-dimensional space.

This color-coded visualization of normals is doing something profound: it's showing you the orientation of the surface at every visible point. Even though we haven't implemented any actual lighting yet, the varying colors create a strong sense of depth and three-dimensionality. Your brain interprets these color gradients as evidence of a curved surface, even though you know intellectually that you're just looking at a flat image on a screen.

What you've accomplished in this lesson is a crucial stepping stone toward realistic rendering. Surface normals are the foundation of almost all lighting calculations in computer graphics. In upcoming lessons, when we implement proper lighting models like diffuse and specular reflection, we'll use these same normal vectors to calculate how light bounces off the surface. The Phong reflection model, for instance, uses the angle between the surface normal and the light direction to determine how bright a surface appears. By learning to compute and visualize normals now, you're preparing yourself for these more advanced techniques.

In the practice exercises that follow, you'll get hands-on experience experimenting with this normal-based shading. You'll try positioning spheres at different locations, observe how the colors change based on the sphere's position relative to the camera, and explore what happens when you modify the normal calculation. These exercises will deepen your intuition about how surface orientation affects appearance and prepare you for the next major step in your ray tracing journey: implementing realistic lighting that will make your scenes truly come alive.