Fixing Rendering Artifacts

Introduction: Subtle Problems with Big Impact

In the previous lesson, you built a recursive path tracer that simulates realistic light transport through Lambertian diffuse materials . Your ray tracer can now render matte surfaces with natural shading, and light bounces between objects, creating subtle color bleeding effects. This was a major achievement, transforming your simple ray tracer into something that simulates real-world physics. However, if you look closely at your rendered images, you might notice two issues that detract from the overall realism. The first issue is subtle but annoying once you notice it. You might see small dark speckles or patterns scattered across surfaces that should be smoothly shaded. These artifacts look like noise or dirt on the surface, and they appear even in areas that should be uniformly lit. This problem is called shadow acne, and it's caused by floating-point precision errors in our ray-surface intersection calculations. The second issue is more obvious: your images probably look darker than they should. The bright areas aren't as bright as you'd expect, and the overall image feels muddy or underexposed. This happens because we're not accounting for how human vision perceives brightness and how display devices expect color values to be encoded. These might seem like minor technical details, but they have a significant impact on the final image quality. Shadow acne breaks the illusion of smooth surfaces and makes your renders look amateurish. Incorrect brightness perception makes your carefully calculated lighting look wrong, wasting all the effort you put into simulating realistic light transport. In this lesson, we'll fix both of these problems with relatively simple solutions that will dramatically improve your rendered images. By the end, you'll understand why these artifacts occur and how to prevent them, giving your ray tracer the polish it needs to produce truly professional-looking results.

Understanding Shadow Acne

Join the 1M+ learners on CodeSignal

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

Fixing Shadow Acne with an Epsilon Offset

The solution to shadow acne is surprisingly simple: we introduce a minimum hit distance, often called an epsilon or bias value. Instead of accepting intersections at any distance greater than zero, we only accept intersections that are at least some small distance away from the ray origin. This small offset ensures that when a ray bounces off a surface, it won't immediately intersect that same surface again due to precision errors.

The key insight is that we don't need perfect precision. We just need to ensure that the scattered ray starts far enough from the surface that numerical errors won't cause false self-intersections. By requiring hits to be at least 0.001 units away from the ray origin, we create a small "dead zone" around the starting point where intersections are ignored. This dead zone is large enough to encompass any floating-point precision errors but small enough that it doesn't affect the visual accuracy of the scene.

The value 0.001 works well for most scenes because it's much larger than typical floating-point errors (which are on the order of 1e-15) but much smaller than the features we're trying to render. If your spheres have radii of 0.5 or larger and your scene spans several units, an offset of 0.001 is essentially invisible. It's like adding a coat of paint that's one-thousandth of a unit thick to every surface. You can't see it, but it prevents the numerical issues.

In our ray tracer, we apply this fix in the ray_color function when we test for intersections. Here's the relevant line:

C++

if (world.hit(r, 0.001, 1e30, rec)) {

if (world.hit(r, 0.001, 1e30, rec)) {

The second parameter to the hit function is the minimum hit distance. By passing 0.001 instead of 0.0, we tell the intersection test to ignore any hits closer than 0.001 units from the ray origin. When a ray bounces off a surface, the scattered ray starts at the hit point, and this epsilon offset prevents it from immediately hitting the same surface again.

You might have noticed that we actually introduced this change in the previous lesson when we implemented the recursive path tracer. At the time, we mentioned it briefly but didn't explain the reasoning in detail. Now you understand why this small change is necessary. Without it, your images would be covered in shadow acne artifacts. With it, surfaces render smoothly and cleanly.

It's worth noting that the choice of epsilon value can depend on your scene scale. If you're rendering a scene where objects are very small (say, measured in millimeters), you might need a smaller epsilon like 0.00001. Conversely, if you're rendering astronomical scales, you might need a larger epsilon. The key is to choose a value that's much larger than your floating-point precision errors but much smaller than the smallest features you care about in your scene. For typical scenes measured in units of meters or similar scales, 0.001 is a good default choice.

Understanding Gamma Correction

The second issue we need to address is that our rendered images look too dark. This isn't a bug in our lighting calculations. The problem is more subtle: it's a mismatch between how we calculate light intensity and how display devices and human vision work. Our ray tracer performs all lighting calculations in what's called linear space, where doubling the number of photons doubles the calculated brightness value. This is physically correct and necessary for accurate light transport simulation. However, both human vision and display monitors are nonlinear, which means they don't respond to light intensity in a linear way.

Human vision is more sensitive to changes in dark tones than in bright tones. If you're in a dark room and someone turns on a small lamp, the change is very noticeable. But if you're already in a brightly lit room and someone adds another lamp of the same brightness, the change is barely perceptible. This nonlinear response is an evolutionary adaptation that helps us see detail in shadows while not being overwhelmed by bright highlights. Mathematically, our perception of brightness is roughly proportional to the actual light intensity raised to a power less than one.

Display devices also have a nonlinear response, though for different reasons. Traditional CRT monitors had a natural gamma curve due to the physics of how electron guns excite phosphors. Modern LCD and OLED displays don't have this physical limitation, but they emulate the same behavior for compatibility. The standard gamma value for most displays is approximately 2.2, which means that if you send a value of 0.5 to the display, it doesn't produce 50% of the maximum brightness. Instead, it produces roughly 22% of the maximum brightness (0.5 raised to the power of 2.2).

This creates a problem for our ray tracer. We calculate lighting in linear space, where a value of 0.5 represents 50% of the maximum light intensity. But when we write this value directly to an image file and display it on a monitor, the monitor interprets it according to its gamma curve and displays only 22% brightness. The result is that our images look much darker than intended. Bright areas that should be at 50% brightness appear at 22%, and the entire image shifts toward darkness.

The solution is gamma correction, which is the process of encoding our linear light values in a way that accounts for the display's nonlinear response. We need to transform our linear values so that when the display applies its gamma curve, the result matches our intended brightness. If the display has a gamma of 2.2, we need to apply the inverse operation (raising values to the power of 1/2.2) before sending them to the display. This way, when the display applies its gamma curve, the two operations cancel out and we get the correct brightness.

In practice, we often use a simplified gamma correction with a gamma value of 2.0 instead of 2.2. This is partly for historical reasons and partly because the math is simpler. Raising a value to the power of 1/2.0 is the same as taking the square root, which is a fast operation that most processors can do efficiently. The difference between gamma 2.0 and gamma 2.2 is small enough that it's not visually significant for most applications, and the simplicity and speed of the square root operation make it an attractive choice.

Implementing Gamma Correction

Now let's implement gamma correction in our ray tracer. The correction needs to happen at the very end of our rendering pipeline, right before we write color values to the output file. We perform all our lighting calculations in linear space to maintain physical accuracy, and only at the final step do we convert to gamma-corrected space for display.

The implementation goes in the write_color function in color.h. This function takes the accumulated color from all the samples for a pixel and converts it to the final output values. Here's the complete updated function:

C++

inline void write_color(std::ostream& out, color pixel_color, int samples_per_pixel) {
    const double scale = 1.0 / samples_per_pixel;

    double r = std::sqrt(pixel_color.x() * scale);
    double g = std::sqrt(pixel_color.y() * scale);
    double b = std::sqrt(pixel_color.z() * scale);

    r = std::clamp(r, 0.0, 0.999);
    g = std::clamp(g, 0.0, 0.999);
    b = std::clamp(b, 0.0, 0.999);

    out << static_cast<int>(256 * r) << ' '
        << static_cast<int>(256 * g) << ' '
        << static_cast<int>(256 * b) << '\n';
}

inline void write_color(std::ostream& out, color pixel_color, int samples_per_pixel) {
    const double scale = 1.0 / samples_per_pixel;

    double r = std::sqrt(pixel_color.x() * scale);
    double g = std::sqrt(pixel_color.y() * scale);
    double b = std::sqrt(pixel_color.z() * scale);

    r = std::clamp(r, 0.0, 0.999);
    g = std::clamp(g, 0.0, 0.999);
    b = std::clamp(b, 0.0, 0.999);

    out << static_cast<int>(256 * r) << ' '
        << static_cast<int>(256 * g) << ' '
        << static_cast<int>(256 * b) << '\n';
}

Let's walk through this function step by step to understand what's happening. The function receives pixel_color, which is the sum of all the color samples we took for this pixel during antialiasing. If we took fifty samples per pixel, this color value is the sum of fifty separate ray color calculations. The first thing we need to do is average these samples by dividing by the number of samples. We calculate a scale factor that's the reciprocal of the sample count, which we'll multiply by each color component.

The crucial step is the next three lines where we apply the square root function to each color channel. Notice that we multiply by the scale factor inside the square root operation. This is important because we want to stay in linear space for as long as possible. We first scale the accumulated color to get the average (still in linear space), then apply the square root to convert from linear space to gamma space. The std::sqrt function performs the gamma correction with gamma equals 2.0, transforming our linear light values into values that will display correctly on a monitor.

After gamma correction, we clamp each color component to the range zero to 0.999 using std::clamp. This ensures that our values are within the valid range for output. Values might exceed one due to very bright areas in the scene or numerical issues, and we need to bring them back into range. We use 0.999 instead of 1.0 as the upper bound because we're going to multiply by 256 in the next step, and we want to ensure the result is at most 255 (since 256 times 0.999 is 255.744, which truncates to 255).

Finally, we convert from floating-point values in the range zero to 0.999 to integer values in the range zero to 255. We multiply each component by 256 and cast to an integer, which truncates any fractional part. This gives us the final RGB values that we write to the PPM file. These values are now gamma-corrected and ready for display.

The order of operations here is important. We must perform the averaging (scaling) before the gamma correction because averaging is a linear operation that should be done in linear space. If we applied gamma correction first and then averaged, we'd get incorrect results because gamma correction is nonlinear. Similarly, we clamp after gamma correction because the valid range for display is in gamma space, not linear space.

When you render an image with this gamma correction in place, you'll immediately notice that it looks much brighter and more natural. Areas that were muddy and dark will now have proper brightness. The overall contrast will improve, with better separation between light and dark areas. The image will look more like what you'd expect from a photograph of the scene rather than an underexposed image.

It's worth emphasizing why we chose gamma 2.0 instead of the more accurate 2.2. The difference in visual appearance is minimal for most scenes. A gamma of 2.0 gives us slightly brighter images than 2.2, but the difference is subtle. The advantage of using 2.0 is that the square root operation is much faster than raising to an arbitrary power. Most processors have dedicated hardware for square root calculations, making it nearly as fast as basic arithmetic. If we used gamma 2.2, we'd need to use the std::pow function, which is significantly slower. For a ray tracer that might calculate millions of pixels, this performance difference adds up.