Refraction of light #

Refraction happens when a light ray hits another medium as shown in the following image:

Of course, this is just a simplified model of how light travels through space and how light is modeled, but this is fine enough to render some pleasant pictures.

According to Snell’s law, the following equation holds (for dielectric-dielectric, e.g. air to glass):

The index of refraction in vacuum is \(1.0\) and for some glass material it might be for instance \(1.6\) . Assuming that \(n_1 = 1.0\) and \(n_2 = 1.6\) we can compute for an given incident ray the direction of the refracted ray. E.g. if \(\theta_{i} = 45°\) (angle of incidence) the corresponding \(\theta_{t}\) angle (angle of refraction) will be approximately \(26.23°\) . The refractive index is defined as \(n = \frac{c}{v}\) where \(c\) is the speed of light in vacuum and \(v\) is the speed of light in the corresponding medium.

Total internal reflection describes the behavior that at some angles no light is refracted (starting at the critical angle) but instead is only reflected. Total internal reflection is the reason for Fata Morganas, e.g. a wet-looking road on a hot day.

Critical Angle #

The critical angle at which total internal reflection happens can be computed using this formula:

Total internal reflection only happens if \(n_1 > n_2\) holds, which means it does not happen if we go from an optical “sparser” medium to an optical “denser” medium.

Index of refraction #

Here is a small table that gives some typical examples for the index of refraction for different materials:

Examples #

The following table list some examples for a 2D scenario where we have an incident ray from “above” and hitting the interface between two different medium types.

A test-driven development approach to implement ray refraction #

According to test-driven development, we write first a test before starting with the implementation.

But is test-driven development really worth the effort?

Thomas Willberger Founder, CEO and realtime rendering developer at Enscape3D once wrote in a Twitter tweet: “Software wisdom: Start with the best-debuggable, most simple implementation. Iron out early mistakes and add tests BEFORE adding bells and whistles. It‘s invaluable to know that the core part works and you do not have to suspect the whole codebase when hunting a bug.”

Let’s write a test for a refract function. First, we have to think about a proper design. The refract function expects three input parameters: \(\omega_i\) , \(n\) (a normal vector) and \(\eta\) . \(\omega_i\) is the vector that points in the opposite direction of the incident vector. This is a common convention: \(\omega_i\) points always towards the light source direction. So to say, \(\omega_i\) is the negative direction of the incoming light. \(n\) is the normal vector that points towards the direction from which the incoming ray is originating. \(\eta\) is computed as the fraction of \(n_2\) and \(n_1\) where \(n_1\) is refraction index of the medium form which the incoming ray is coming from. As an output parameter the refraction function is expected to compute the refraction vector, if there is no total internal reflection.

When looking at the source code of PBRTv3 the refraction function as four parameters.

inline bool Refract(const Vector3f &wi, const Normal3f &n, 
                    Float eta, Vector3f *wt)

PBRTv3 uses the fourth parameter as an output parameter for the computed refracted vector. PBRTv3 has the convention that for output parameters always pointers are used. Furthermore, the function returns true if there was no total internal reflection.

I decided to use a similar form for my refraction function. Instead of using a pointer for the computed refraction vector, I decided to use a reference value.

This is the test I came up with after several iterations:

TEST(RefractionVacuumToGlass, 
     Given_IncidentVectorIs45Degrees_When_ComputingRefraction_Then_RefratedVectorIsAbout26Degrees) {
    // Arrange
    const Normal2f normal{0.f, 1.f};
    Vector2f incident{1.f, -1.f};
    Vector2f wi = -incident;
    wi.normalize();

    const auto refraction_index_vacuum = 1.f;
    const auto refraction_index_glass = 1.6f;

    // Act
    Vector2f refracted_direction;
    bool valid_refraction = refract(
            wi, 
            normal, 
            refraction_index_vacuum / refraction_index_glass, 
            refracted_direction);

    // Assert
    EXPECT_TRUE(valid_refraction);
    EXPECT_TRUE(refracted_direction.x() > 0.f);
    EXPECT_TRUE(refracted_direction.y() < 0.f);

    EXPECT_THAT(refracted_direction.norm(), testing::FloatEq(1.f));

    float theta = degree_to_radian(26.23f);
    Eigen::Rotation2Df rotation_transform(theta);
    Vector2f rotated_vector = 
            rotation_transform.to_rotation_matrix() * Vector2f{0.f, -1.f};

    EXPECT_THAT(refracted_direction.x(), 
                testing::FloatNear(rotated_vector.x(), .0001f));
    EXPECT_THAT(refracted_direction.y(), 
                testing::FloatNear(rotated_vector.y(), .0001f));
}

The test makes use of the Arrange-Act-Assert pattern.

To keep it simple the unit test considers only the 2D case, but the test can be extended easily to 3D. Actually, my refract function is a template function that can handle 2D and 3D vectors at the same time. In test-driven development it is always a good idea to start first with the most simple test and then switch later on to more complex scenarios. This will probably save you some headaches when it comes to debugging.

The fun part now is to implement this unit test. Now it’s your turn.

I have created I small video where I show how I do TDD when writing a ray tracer. It does not cover the refract function but shows how to implement scaling in a ray tracer:

You can find the source code of this ray tracer on GitHub: https://github.com/Vertexwahn/FlatlandRT