# The Ray Tracer Challenge: various errata

**URL:** <https://forum.devtalk.com/t/the-ray-tracer-challenge-various-errata/3554>\
**Category:** PragProg Customers\
**Tags:** book-the-ray-tracer-challenge, errata\
**Created:** [29 October 2020 18:48 UTC](https://forum.devtalk.com/t/the-ray-tracer-challenge-various-errata/3554 "2020-10-29T18:48:00Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![jamis](https://forum.devtalk.com/user_avatar/forum.devtalk.com/jamis/32/1083_2.png) [@jamis](https://forum.devtalk.com/u/jamis)\
**Post date:** [29 October 2020 18:48 UTC](https://forum.devtalk.com/t/the-ray-tracer-challenge-various-errata/3554/1 "2020-10-29T18:48:00Z")

</div>

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](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](https://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](https://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](https://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 ![:)](https://storage.proboards.com/forum/images/smiley/smiley.png)

- 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.

---

<div class="post-metadata">

**Author:** ![PetroCoder](https://forum.devtalk.com/user_avatar/forum.devtalk.com/petrocoder/32/2844_2.png) [@PetroCoder](https://forum.devtalk.com/u/PetroCoder)\
**Post date:** [24 May 2021 17:16 UTC](https://forum.devtalk.com/t/the-ray-tracer-challenge-various-errata/3554/2 "2021-05-24T17:16:12Z")

</div>

In these two tests (p222 and p223):

```auto
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?

---

<div class="post-metadata">

**Author:** ![jamis](https://forum.devtalk.com/user_avatar/forum.devtalk.com/jamis/32/1083_2.png) [@jamis](https://forum.devtalk.com/u/jamis)\
**Post date:** [24 May 2021 20:16 UTC](https://forum.devtalk.com/t/the-ray-tracer-challenge-various-errata/3554/3 "2021-05-24T20:16:37Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![PetroCoder](https://forum.devtalk.com/user_avatar/forum.devtalk.com/petrocoder/32/2844_2.png) [@PetroCoder](https://forum.devtalk.com/u/PetroCoder)\
**Post date:** [25 May 2021 09:44 UTC](https://forum.devtalk.com/t/the-ray-tracer-challenge-various-errata/3554/4 "2021-05-25T09:44:21Z")

</div>

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