Creating the Hit Record

1. What Information Does an Intersection Carry?

When a ray intersects an object, what are the fundamental pieces of information we need to capture? At a minimum, we need to know the location of the hit and the orientation of the surface at that point.

The YouTuber Sebastian Lague provides a great high-level overview of this concept in his ray tracing series. He refers to this data packet as "hit info".

His list—hit/miss status, distance, position, and normal—forms the core of our hit_record. The hit method's bool return value handles the hit/miss status, so our struct will focus on the other three.

Let's look at the C++ implementation from the Ray Tracing in One Weekend guide. This is the initial version of the hit_record we sketched out in the last lesson, now with its purpose made clear.

Based on this, our hittable.h file should contain this initial hit_record definition:

#ifndef HITTABLE_H
#define HITTABLE_H

#include "ray.h"

class hit_record {
  public:
    point3 p;      // The world-space coordinate of the intersection point.
    vec3 normal;   // The surface normal vector at the intersection point.
    double t;      // The parameter 't' along the ray where the intersection occurred.
};

// ... our hittable abstract class from the previous lesson follows ...

Let's break down these members:

• point3 p: The actual 3D point in space where the ray pierced the object's surface.
• double t: The value such that ray.at(t) equals p. This scalar is crucial for determining which intersection is the closest to the camera when a ray hits multiple objects. We always want the one with the smallest positive t.
• vec3 normal: The vector perpendicular to the surface at point p. This is fundamental for all shading calculations—it tells us how the surface is oriented towards light sources and the camera.

2. A Subtle Problem: Inside or Outside?

Our current hit_record is a great start, but it has a limitation. Imagine a ray hitting a glass sphere. If the ray originates outside the sphere, the normal should point outwards. But if the ray originates inside the sphere and is on its way out, we might need the normal to point inwards for refraction calculations.

Your experience in VFX and DCCs means you're likely familiar with this concept, often represented as "two-sided" materials or the need to "flip normals." We need a robust way to handle this in our code.

The solution is to always have our geometry calculation produce an "outward" pointing normal, and then, based on the ray's direction, decide which side of the surface was hit. We can then store a consistently oriented normal (e.g., one that always points against the incoming ray) in our hit_record.

This requires a small but significant enhancement to our hit_record struct.

After incorporating this change, our hit_record in hittable.h will look like this:

class hit_record {
  public:
    point3 p;
    vec3 normal;
    double t;
    bool front_face; // Flag to indicate if the ray hit the front or back of the surface.

    // A helper method to set the normal vector and the front_face flag.
    void set_face_normal(const ray& r, const vec3& outward_normal) {
        // Sets the hit record normal vector.
        // NOTE: the parameter `outward_normal` is assumed to have unit length.

        front_face = dot(r.direction(), outward_normal) < 0;
        normal = front_face ? outward_normal : -outward_normal;
    }
};

The logic in set_face_normal is elegant and efficient:

1. It calculates the dot product of the ray's direction and the geometry's outward-facing normal.
2. If the dot product is negative, the vectors are pointing in generally opposite directions, meaning the ray hit the object from the outside (a "front face" hit).
3. If the dot product is positive, the vectors point in similar directions, meaning the ray originated inside the object.
4. It then sets the normal member to always point against the incident ray, which simplifies later shading calculations.

3. Looking Ahead: What is the Surface Made Of?

We now have a robust way to describe the geometry of an intersection. But for shading, we need one more piece of information: what is the surface made of? Is it diffuse like matte paint, reflective like metal, or transparent like glass?

In a real-time game engine or a production renderer, this information is stored in a material. The hit_record is the perfect place to store a reference to the material of the object that was hit.

Let's add this final piece to our hit_record. This is a forward-looking step that prepares our data structure for the material and shading systems we will build in Module 7.

Here is our final, complete hit_record for this module:

#ifndef HITTABLE_H
#define HITTABLE_H

#include "ray.h"
#include <memory> // Required for std::shared_ptr

// Forward declaration to resolve circular include dependencies.
// The hittable objects need to know about materials, and materials will need to know about hittables.
class material;

class hit_record {
  public:
    point3 p;
    vec3 normal;
    std::shared_ptr<material> mat_ptr; // A pointer to the material of the hit object.
    double t;
    bool front_face;

    void set_face_normal(const ray& r, const vec3& outward_normal) {
        front_face = dot(r.direction(), outward_normal) < 0;
        normal = front_face ? outward_normal : -outward_normal;
    }
};

// ... the hittable abstract class ...

Notice two C++ details here:

1. class material;: This is a forward declaration. It tells the compiler "a class named material exists," without needing the full definition. This is necessary because hittable.h refers to material, and soon material.h will refer to hit_record.
2. std::shared_ptr<material>: We use a smart pointer to manage the material's memory. Multiple objects might share the same material, and std::shared_ptr handles this ownership scenario automatically. This reinforces the memory management concepts from our first module.

Conclusion

In this lesson, we have meticulously designed the hit_record, a data structure that is central to our ray tracer's architecture. It serves as a comprehensive report detailing everything we need to know about a point of intersection.

Key Takeaways:

• A hit_record bundles all information about a ray-object intersection.
• The core members are the intersection point (p), the surface normal (normal), and the ray parameter (t).
• A robust hit_record also handles surface directionality (front_face and a helper method) to distinguish between hitting an object from the outside versus the inside.
• Including a pointer to the object's material makes the hit_record a complete data packet, connecting the geometry stage to the shading stage.

With this structure in place, our hittable::hit method now has a standardized way to report its findings.

Next Steps

We now have an abstract hittable interface and a hit_record struct to store results. But how do we manage a scene containing many hittable objects? In the next lesson, we will create a hittable_list class, a container that can hold any object that implements our hittable contract, allowing us to build and render our first multi-object scene.