Shadows (Ch.8) over_point epsilon of 0.00001 causes acne

Hello Robert,

Yeah, 0.01 is big enough to cause other problems down the road. It seems odd, too, that the acne is only occurring on the walls and floor, and not on the subject spheres. This makes me wonder if there might not be something off about how the transforms applied to the walls/floor (specifically, the scaling) are interacting with the computation of the normal vector in prepare_computations. (If this were so, though, I would also expect the lighting on those elements to be strange...)

One thing you might try to investigate: find one particular pixel in the acne'd version, and then modify your render function so it only renders that pixel. Then you can step through the code (if debuggers are your thing) or sprinkle your code with print statements (if you're printist) to get more information about the state of your scene and your renderer at that point.

Also, if your code is available anywhere for me to look at, I'd be happy to take a peek and see if anything jumps out at me.

- Jamis

Hi Robert,
would it be possible to test with 64 bit floats instead?

Argh, that's what I get for forgetting that premature optimization is the root of all evil... The acne disappears when I use f64, however a few tests fail now (difference of 0.0001, thus larger than epsilon), I'll have to look into those. Thank you :-)

@jamis: Quick question: What bit-size did you use for the test values? e.g. using the epsilon of 0.00001 I have this failure, and I wonder whether the test values aren't meant to be 32-bit...:

---- material::tests::test_lighting_with_eye_in_the_path_of_the_reflection_vector stdout ----
thread 'material::tests::test_lighting_with_eye_in_the_path_of_the_reflection_vector' panicked at 'assertion failed: `(left == right)`
 left: `Color { red: 1.63638, green: 1.63638, blue: 1.63638 }`,
right: `Color { red: 1.6363961030678928, green: 1.6363961030678928, blue: 1.6363961030678928 }`', src/material.rs:131:9

We have different print runs ;-) My copy has no page xix, on page xvii it says 0.0001, but on page 5 it is 0.00001. According to the thread epsilon weirdness that's a mistake, but using 0.0001 for tests is still fine, while using 0.00001 is the recommended value for the "production" code. Given how I've implemented the operator overload for Equality though, I have to use the "production" value.

I've run across the exact same issue. I'm using C# and using the SIMD optimized Vector4 & Matrix4x4 from System.Numerics, so it's not exactly trivial for me to change to a double-precision float. I'm kinda hoping that the problem goes away once real planes are implemented in the next chapter...

EDIT: Planes do not have the issue, but it doesn't really solve the problem.  It seems to show up whenever a sphere is extremely deformed.

EDIT2: To get around it I made a FarOverPoint property on Computation that's shifted farther out and use that only for determining if a point is in shadow.  We'll see if it causes more problems later.

That's a lot more black than I would expect for an acne problem. I'd be curious to see what the computed values are within the lighting() function for a single black pixel of that plane. It might shed some light (ha!) on the issue.

- Jamis

I have just noticed that sometimes color_at(w, r) is being passed an "undefined" ray. It is called in render(c, w). It means that this line: "var r = c.ray_for_pixel(x, y);" in render(c, w) is sometimes not returning a defined ray... Here is the code in the camera class/object definition for camera.ray_for_pixel(px, py)….

this.ray_for_pixel = function(px, py) {

var xoffset = (px + 0.5) * this.pixel_size;
var yoffset = (py + 0.5) * this.pixel_size;

var world_x = this.half_width - xoffset;
var world_y = this.half_height - yoffset;

var input1 = inverse(this.transform);
var input2 = point(world_x, world_y, -1);

//debugger;

var pixel = multiply_tuple_by_matrix(input1, input2);
var origin = multiply_tuple_by_matrix(inverse(this.transform), point(0,0,0));
var direction = normalize(subtract(pixel, origin));

return new ray(origin, direction);

}

I don't know why it wouldn't return a ray, but ho-hum....

EDIT: I did a quick test, and origin and direction are always successfully created as tuples....

EDIT2: I think it may have been a false alarm, I think I had a brain-fart. But, see below...