Creating Light Sources with Emissive Materials

1. From Fictional Lights to Physical Light Sources

In many graphics applications, especially in real-time rasterization, we use conceptual lights like point lights (infinitely small), directional lights (infinitely far away), and spotlights. While computationally convenient, these are physically inaccurate fictions. In the real world, light is emitted from surfaces that have area—a light bulb filament, a neon sign, a TV screen.

Our goal is to simulate this reality. Instead of adding a "light" object to our scene, we'll give our geometric objects a new property: the ability to emit light. This is what an emissive material does.

The following video provides an excellent conceptual overview of why this approach is more physically grounded and a better fit for a path tracer.

As the video explains, a key principle in physically-based rendering is energy conservation. A non-emissive surface cannot reflect more light than it receives. Emissive materials are the only ones that break this rule by adding energy (light) to the scene.

2. Modifying the Material for Emission

To implement this, our material class needs to know two things: what color of light it emits, and how brightly. A common approach is to add an emission color and an emission strength (power) to the material definition.

Our material abstract base class will need a new virtual function that returns the emitted light. For most materials like our existing Lambertian and Metal, this function will simply return black (0,0,0). We will then create a new diffuse_light material that implements this function to return an actual color.

Following the structure of Peter Shirley's books, let's update our material.h:

// In material.h

class material {
    public:
        // By default, materials emit no light.
        virtual color emitted(double u, double v, const point3& p) const {
            return color(0, 0, 0);
        }

        virtual bool scatter(
            const ray& r_in, const hit_record& rec, color& attenuation, ray& scattered
        ) const = 0;
};

Now, let's create a new material class for our lights. This material won't scatter light; it only emits it. When a ray hits it, its path terminates.

Create a new header file, diffuse_light.h:

// In diffuse_light.h

#ifndef DIFFUSE_LIGHT_H
#define DIFFUSE_LIGHT_H

#include "material.h"
#include "texture.h" // Assuming you have a texture class from previous lessons

class diffuse_light : public material {
  public:
    diffuse_light(shared_ptr<texture> a) : emit(a) {}
    diffuse_light(color c) : emit(make_shared<solid_color>(c)) {}

    virtual bool scatter(
        const ray& r_in, const hit_record& rec, color& attenuation, ray& scattered
    ) const override {
        // A light source does not scatter reflected light.
        return false;
    }

    virtual color emitted(double u, double v, const point3& p) const override {
        // Return the light's own color.
        return emit->value(u, v, p);
    }

  private:
    shared_ptr<texture> emit;
};

#endif

This approach, creating a distinct material type for lights, is clean and object-oriented. The article "Ray Tracing in One Weekend: Part 7 Lights" (LINK), which implements these concepts in Rust, demonstrates the same design pattern.

3. Updating the Render Loop

With our materials updated, we must now change our main ray_color function to handle emission. This is where the logic of path tracing begins to truly take shape.

Previously, color was only determined at the end of a ray's journey, when it hit the sky. Now, light can be added at any bounce.

The logic changes as follows:

1. When a ray intersects an object, we first ask the material for any light it emits. This is the light generated at the hit point itself.
2. We then ask the material if the ray scatters. If it does, we recursively call ray_color for the new scattered ray. The color returned from this recursive call represents the light coming from elsewhere in the scene.
3. The final color for the pixel is the sum of the emitted light plus the scattered light.

Here is the updated ray_color function:

// In main.cpp or wherever your ray_color function is

color ray_color(const ray& r, const hittable& world, int depth) {
    hit_record rec;

    // If we've exceeded the ray bounce limit, no more light is gathered.
    if (depth <= 0)
        return color(0,0,0);

    // If the ray hits nothing, return a background color. For now, let's make it black.
    // The scene will be lit only by our emissive objects.
    if (!world.hit(r, 0.001, infinity, rec))
        return color(0,0,0);

    ray scattered;
    color attenuation;
    color emitted = rec.mat_ptr->emitted(rec.u, rec.v, rec.p);

    if (!rec.mat_ptr->scatter(r, rec, attenuation, scattered))
        return emitted; // If it doesn't scatter, we only get the emitted light.

    // If it does scatter, we get emitted light PLUS light from subsequent bounces.
    return emitted + attenuation * ray_color(scattered, world, depth-1);
}

This is a profound change. The attenuation * ray_color(...) part handles reflected light, while the emitted part handles light generated directly at the surface.

4. Lighting Up the Scene

Now for the rewarding part. Let's create a scene and add a light source. You can modify your scene generation code to add a sphere or a new rectangle primitive and assign it a diffuse_light material.

// In your scene setup function
// ...
auto light_mat = make_shared<diffuse_light>(color(4, 4, 4));
world.add(make_shared<sphere>(point3(0, 2, 0), 0.5, light_mat));
// ... add other objects

When you render this, you'll see something remarkable. The sphere will not only appear bright white, but it will also cast light onto the other objects in the scene, producing beautiful, soft shadows automatically.

The following video segments demonstrate the code integration and the stunning visual results. While the code structure might differ slightly from our implementation (e.g., adding emission properties to all materials instead of a new class), the changes to the render loop and the final effect are identical.

The soft shadows you see are not the result of a special "soft shadow" algorithm. They are a natural, emergent property of tracing light paths from area sources. This is a core reason why path tracing is the standard for photorealistic rendering in VFX and animation.

Conclusion

Congratulations on implementing your first physically-based light source! This is a major milestone.

Key Takeaways:

• Emissive materials allow any object to become a light source, which is a more physically accurate model than abstract point or directional lights.
• The implementation involves adding an emitted() method to your material interface and creating a specific diffuse_light material.
• The ray_color function is updated to accumulate light at each bounce by adding the material's emission to the color contributed by scattered rays.
• This approach naturally produces realistic soft shadows without any specialized shadow code.

Next Steps

We have now built the core components of a simple path tracer. Our renderer simulates light bouncing around a scene, gathering light from emissive sources. But what we've done is an intuitive implementation. To build upon this and add more advanced features, it's crucial to understand the formal theory that underpins it all.

In the next lesson, we will introduce the Rendering Equation, the formal mathematical basis for all physically-based rendering. We will see how our current ray_color function is actually a recursive Monte Carlo solver for this equation, a technique known as path tracing.