Things to Watch Out For

A ray tracer is math-heavy. There’s no getting around it. It works its magic by crunching numbers, finding intersections between lines and shapes, computing reflections and refractions, and blending colors. So, yes, there will be a great deal of math here, but I will mostly give it to you, ready to implement. You’ll find little or no focus on where the math comes from, no derivations of formulas, no explanations of why an equation does what it does. You’ll see the formulas and, where necessary, walk through how to implement them, but you won’t wade through proofs and derivations. If the proofs and derivations are what you particularly enjoy, you can always find a great deal of information about them online.

Also, number-crunching tends to be fairly CPU-intensive. A ray tracer offers a lot of opportunities to optimize code, but that’s not the focus of this book. If you follow along and implement just what is described, your code will probably not be very efficient or very fast—but it will work. Think of optimization as a bonus exercise!

Other things to watch out for, in no particular order, are these:

Comparing floating-point numbers

Especially in tests, you’ll need to be able to compare two floating-point numbers to determine if they are approximately equal. The specifications in the book represent this loose comparison with a simple equals sign. In practice, you’ll need to be more explicit and test that the two numbers are within an error value that the book refers to as EPSILON, something like this: |a - b| < EPSILON. In practice, using a tiny value like 0.0001 for EPSILON is generally fine.

Comparing data structures

As with comparing numbers, it’s also assumed that you’ll need to compare data structures to see if they are equal. For example, you’ll need to be able to see whether two points are the same. These comparison routines aren’t explicitly described in the book, but you’ll need to implement them all the same. It wouldn’t hurt to add tests for these routines, too, despite them not being given in the book.

Representing infinity

In later chapters, like Chapter 12, ​Cubes​, and Chapter 13, ​Cylinders​, you’ll need to be able to compare numbers with infinity. If your programming language can represent infinity natively, that’s great! Otherwise, you can usually fake it by using a very large number instead. (Something like 1×10¹⁰ is usually plenty. In many programming languages, you can write that as 1e10.)

Use your own names and architecture!

The names of functions and variables given in the book are just recommendations. The functions are designed so that the first argument is the “responsible party,” or the entity with responsibility for the domain in question. In object-oriented terms, the first argument would be the self object. But don’t let this stop you from reassigning those responsibilities if you prefer. You should always feel free to choose names more appropriate to your own architecture.

Also, the ray tracer will be described imperatively, but you should look for ways to adapt these descriptions to the strengths and idioms of your programming environment. Embrace your classes, modules, namespaces, actors, and monads, and make this ray tracer your own!

A lot of work has gone into making sure everything in this book is accurate and error-free, but nobody’s perfect. If you happen to find a mistake somewhere, please let me know about it. You can report errata on the book’s web site.^[4] And be sure to visit the book’s discussion forum,^[5] where you can ask questions, share tips and tricks, and post eye candy you’ve rendered with your ray tracer. This forum is purely my own and is not affiliated with the Pragmatic Bookshelf in any way.

With all that out of the way, brace yourself—we’re going to jump right in and get started. This is going to be fun!