The Ray Tracer Challenge: various errata

The following is cross-posted from the original Ray Tracer Challenge forum, from a post by garfieldnate. I’m cross-posting it so that the errata can be kept in a single place.

Original post here: https://forum.raytracerchallenge.com/thread/203/performance-tips-clarifications-book-errata

Possible/Definite Errata

These are points where following the book exactly caused incorrect behavior in my implementation.

The “A ray misses a cube” test needs one more case: the ray is cast away from the cube. Not implementing this will make cubes always appear in front of the camera, even if placed behind it. Here is another test case where the ray should miss the cube:

|point(0, 0, 2) | vector(0, 0, 1)|

Fixing the book’s algorithm: at the end of the method, if tmax is negative then no intersection should be reported. The algorithm given in the book allows tmax to be a negative number, indicating an intersection opposite the ray’s direction.

Cylinder cap intersection should NOT have object_ray.direction.y <= REALLY_SMALL_POSITIVE_NUMBER as a quick return.
Cone and cylinder side intersections required checking a.abs() and b.abs() against REALLY_SMALL_POSITIVE_NUMBER; exact checking against 0 did not work at all.
For the second test case given for “Intersecting a cone with a ray”, I had to change -5 to -4.999999 to get the ray to intersect with the cone.
The cylinder azimuth calculation should be performed with x and z, not x and y.
Bonus bounding box chapter: there is no bounding box specified for smooth triangles; though I did not end up implementing this, I’m certain the algorithm has to be different from that used for regular triangles.
Bonus UV mapping chapter: the provided cross diagram for UV mapping of a cube is wrong for up and down

Up and down should both map x positively. The tests are correct. I found another chart with the correct mapping on wikipedia: en.wikipedia.org/wiki/Cube_mapping#/media/File:Cube_map.svg, but it also makes intuitive sense. Looking up or down from inside the cube, the observer’s x never reverses from the absolute x.

Clarifications

In the cone section: “If a is nonzero, you’ll use the same algorithm, but with the new a, b, and c, that you used for the cylinders.” I found this sentence confusing and it took a while to understand it. I think it would be more clearly written like so: “If a is nonzero, you’ll use the same algorithm (but with the new a, b, and c) that you used for the cylinders.”
Where UV mappers use mod/%, a note should be made that there are several related operations that a programming language might represent with %; particularly, be careful to choose an implementation that always return positive values, even if the input is negative. See the treatment on Wikipedia here: en.wikipedia.org/wiki/Modulo_operation#In_programming_languages. In Rust, I needed to use the rem_euclid function instead of the % operator.
There isn’t any note in the UV chapter on how a cylinder has to be scaled for the texture to look correct, though Jamis demonstrates it in the provided scene YAMLs. As I found a similar issue reported on StackOverflow, I ended up doing a little writeup there to explain the issue and how to fix it: stackoverflow.com/a/60913088/474819
Test “Converting a point from world to object space” should scale by 1,2,3 instead of 2,2,2 to catch more programming errors.

Typos/Small Errata

These will only really be useful for Jamis

Typo in bounding boxes chapter: inculde -> include
Pseudocode for CubeMap’s pattern_at contains uv_cube_left, etc. but these should be cube_uv_left, etc. to be consistent with the previous declarations in the chapter
There are two scenarios named “Checker pattern in 2D” in the UV mapping chapter. The second one should probably be “UV mapping an image” or something like that.
Typo in UV chapter: “Experiment and see what you come up.” (missing “with”)
“non-cubic bounding box” is not a great name for the test in the bounding box chapter; maybe “bounding box not centered at origin” would be clearer.

3 comments

#errata /book-the-ray-tracer-challenge

4 2354 3

2021-05-25 09:44:21 UTC

Most Liked

PetroCoder

In these two tests (p222 and p223):

Scenario: A smooth triangle uses u/v to interpolate the normal
  When i ← intersection_with_uv(1, tri, 0.45, 0.25)

Scenario: Preparing the normal on a smooth triangle
  When i ← intersection_with_uv(1, tri, 0.45, 0.25)

The first parameter t should be qual to 2. The ray intersects the triangle at distance 2, according to my calculations. Could this be an error?

Post #2

jamis

Author of Mazes for Programmers and 1 other title

Hello!

For these two tests, there are no rays being cast—all we’re doing here is creating an intersection record which we’re arbitrarily saying exists at t=1. You could set t=2, but it would make no difference, because the normal calculation is independent of t. For these smooth triangles, the only parameters that matter are u and v (and, of course, the triangle itself).

Does that make sense? Is there something I could be describing better?

Thanks!

Jamis

Post #3

PetroCoder

Hi Jamis,

Thank you for this explanation. It makes perfect sense. In my code, I am also checking (just in case) that all parameters of the intersection are “consistent”, i.e. that there is indeed an intersection with the object at a given value of t. That is why I have spotted this case.

Kind regards,
Petro

Post #4