Abstracting Hits with a Hittable Interface

1. The Problem: A Non-Scalable World

Imagine our current ray_color function. It takes a ray and figures out what color it should be. Inside, it likely loops through a list of sphere objects and calls a hit function on each one.

What happens when we want to add a triangle? We'd have to add a separate list of triangles and another loop. And for a plane? Another list, another loop. The ray_color function becomes a bottleneck of specialized code.

The goal is to have a single, simple loop:

// Desired logic
for (const auto& object : world_objects) {
    if (object.hit(my_ray)) {
        // We found a hit!
    }
}

For this to work, we need to be able to store different types of objects (spheres, triangles, etc.) in a single list (world_objects) and call the same hit method on all of them. This is where polymorphism comes in.

2. The C++ Solution: Abstract Classes and Pure Virtual Functions

To achieve this generic behavior in C++, we use a feature called pure virtual functions. A class containing at least one pure virtual function is called an abstract class.

An abstract class acts as a template or a "contract." It cannot be instantiated on its own. Instead, other classes (like sphere or triangle) must inherit from it and provide concrete implementations for its pure virtual functions.

Your computer science background has likely introduced you to the concept of interfaces or abstract base classes. In C++, this is how we implement that pattern.

To get a clear and practical refresher on how this works in C++, let's watch a video from The Cherno.

The key takeaway is that by defining a function like virtual void do_something() = 0;, we force any derived class to implement do_something() if it wants to be a concrete, usable object. This is exactly the "contract" we need for our geometric primitives.

3. Designing the hittable Interface

Now, let's apply this concept to our ray tracer. We will create an abstract class called hittable. This will be the "contract" that all intersectable objects in our scene must adhere to. The contract is simple: they must provide a hit function.

The blog post "Ray Tracing in One Weekend: Part Two" offers a very clean and direct implementation of this idea.

Let's break down the core of this new header file, hittable.h:

#ifndef HITTABLE_H
#define HITTABLE_H

#include "ray.h"

// We will expand this struct in the next lesson
struct hit_record {
    point3 p;
    vec3 normal;
    double t;
};

class hittable {
  public:
    virtual bool hit(const ray& r, double t_min, double t_max, hit_record& rec) const = 0;
};

#endif

The most important line is the declaration of the hit method:
virtual bool hit(...) const = 0;

• virtual: This keyword tells C++ to use dynamic dispatch. When we call hit on a pointer to a hittable object, the compiler will ensure the correct version of hit (e.g., the sphere's version or the triangle's version) is called at runtime.
• bool hit(...): The function returns true if the ray hits the object within the valid range [t_min, t_max], and false otherwise.
• hit_record& rec: This is an "out parameter." If a hit occurs, the function will populate this struct with information about the intersection (the point p, the normal normal, etc.). We will focus on this struct in detail in the next lesson.
• const: This promises that the hit method will not change the state of the object it's called on. A sphere's radius and center don't change just because a ray intersects it.
• = 0: This makes the function pure virtual, which in turn makes the hittable class abstract.

4. The Object-Oriented Style in Context

This object-oriented design is a classic and powerful way to structure a renderer. It prioritizes flexibility and extensibility. For a high-level view that reinforces this design choice, let's watch a quick segment from a talk by C++ expert Matt Godbolt on path tracing.

As he describes, the core idea is to have an abstraction for scene geometry that can be queried for intersections, which is precisely what our hittable interface accomplishes.

Conclusion

In this lesson, we've laid a critical architectural foundation for our ray tracer. By abstracting the concept of an intersectable object, we've paved the way for a much more complex and interesting world.

Key Takeaways:

• Hardcoding intersection logic for each object type is not scalable.
• An abstract class with a pure virtual function creates a "contract" that derived classes must implement.
• We designed a hittable interface with a pure virtual hit method: virtual bool hit(...) const = 0;.
• This allows us to treat all objects in our scene uniformly, asking each one, "Did this ray hit you?" without needing to know its specific type.

Next Steps

The hittable interface is defined, but it's not useful without two other components: concrete classes that implement it, and a way to store the detailed results of an intersection.

In the next lesson, we will focus on the hit_record struct. We will detail all the information it needs to hold—the intersection point, the t value, the surface normal, and more. Afterward, we will update our sphere class to officially become a hittable object by implementing the hit method.