Revisions from PR commentary

Author: hollasch

books/RayTracingInOneWeekend.html

@@ -33,8 +33,8 @@
 don’t need to. However, I suggest you do, because it’s fast, portable, and most production movie and
 video game renderers are written in C++. Note that I avoid most “modern features” of C++, but
 inheritance and operator overloading are too useful for ray tracers to pass on. I do not provide the
-code online, but the code is real, and I show all of it except for a few straightforward operators
-in the `vec3` class. I am a big believer in typing in code to learn it, but when code is available I
+code online, but the code is real and I show all of it except for a few straightforward operators in
+the `vec3` class. I am a big believer in typing in code to learn it, but when code is available I
 use it, so I only practice what I preach when the code is not available. So don’t ask!
 
 I have left that last part in because it is funny what a 180 I have done. Several readers ended up
@@ -64,7 +64,7 @@
 ====================================================================================================
 
 Whenever you start a renderer, you need a way to see an image. The most straightforward way is to
-write it to a file. The catch is, there are so many formats, and many of those are complex. I always
+write it to a file. The catch is, there are so many formats. Many of those are complex. I always
 start with a plain text ppm file. Here’s a nice description from Wikipedia:
 
   ![](../images/img.ppm-example.jpg)
@@ -140,7 +140,7 @@
 
 <div class='together'>
 Hooray! This is the graphics “hello world”. If your image doesn’t look like that, open the output
-file in a text editor, and see what it looks like. It should start something like this:
+file in a text editor and see what it looks like. It should start something like this:
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     P3
@@ -171,7 +171,7 @@
 loop or other problem.
 
 <div class='together'>
-Our program outputs the image to the standard output stream (`std::cout`), so leave that alone, and
+Our program outputs the image to the standard output stream (`std::cout`), so leave that alone and
 instead write to the error output stream (`std::cerr`):
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
@@ -355,9 +355,9 @@
 ====================================================================================================
 
 <div class='together'>
-The one thing that all ray tracers have is a ray class, and a computation of what color is seen
-along a ray. Let’s think of a ray as a function $\mathbf{p}(t) = \mathbf{a} + t \vec{\mathbf{b}}$.
-Here $\mathbf{p}$ is a 3D position along a line in 3D. $\mathbf{a}$ is the ray origin, and
+The one thing that all ray tracers have is a ray class and a computation of what color is seen along
+a ray. Let’s think of a ray as a function $\mathbf{p}(t) = \mathbf{a} + t \vec{\mathbf{b}}$. Here
+$\mathbf{p}$ is a 3D position along a line in 3D. $\mathbf{a}$ is the ray origin, and
 $\vec{\mathbf{b}}$ is the ray direction. The ray parameter $t$ is a real number (`double` in the
 code). Plug in a different $t$ and $p(t)$ moves the point along the ray. Add in negative $t$ and you
 can go anywhere on the 3D line. For positive $t$, you get only the parts in front of $\mathbf{a}$,
@@ -401,7 +401,7 @@
 </div>
 
 Now we are ready to turn the corner and make a ray tracer. At the core, the ray tracer sends rays
-through pixels, and computes the color seen in the direction of those rays. The involved steps are
+through pixels and computes the color seen in the direction of those rays. The involved steps are
 (1) calculate the ray from the eye to the pixel, (2) determine which objects the ray intersects, and
 (3) compute a color for that intersection point. When first developing a ray tracer, I always do a
 simple camera for getting the code up and running. I also make a simple `color(ray)` function that
@@ -535,8 +535,8 @@
 </div>
 
 <div class='together'>
-The rules of vector algebra are all that we would want here, and if we expand that equation, and
-move all the terms to the left hand side we get:
+The rules of vector algebra are all that we would want here. If we expand that equation and move all
+the terms to the left hand side we get:
 
   $$ t^2 \vec{\mathbf{b}}\cdot\vec{\mathbf{b}}
      + 2t \vec{\mathbf{b}} \cdot \vec{(\mathbf{a}-\mathbf{c})}
@@ -864,11 +864,12 @@
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [Listing [normals-point-against]: <kbd>[sphere.h]</kbd> Remembering the side of the surface]
 
-The decision whether to have normals always point out or to always point against the ray is based on
-whether you want to determine the side of the surface at the time of geometry or at the time of
-coloring. In this book we have more material types than we have geometry types, so we'll go for
-less work, and put the determination at geometry time. This is simply a matter of preference, and
-you'll see both implementations in the literature.
+We can set things up so that normals always point “outward” from the surface, or always point
+against the incident ray. This decision is determined by whether you want to determine the side of
+the surface at the time of geometry intersection or at the time of coloring. In this book we have
+more material types than we have geometry types, so we'll go for less work and put the determination
+at geometry time. This is simply a matter of preference, and you'll see both implementations in the
+literature.
 
 We add the `front_face` bool to the `hit_record` struct. I know that we’ll also want motion blur at
 some point, so I’ll also add a time input variable.
@@ -1029,7 +1030,7 @@
 
 We'll use shared pointers in our code, because it allows multiple geometries to share a common
 instance (for example, a bunch of spheres that all use the same texture map material), and because
-it makes memory management automatic, and easier to reason about.
+it makes memory management automatic and easier to reason about.
 
 `std::shared_ptr` is included with the `<memory>` header.
 
@@ -1178,10 +1179,10 @@
 
 When a real camera takes a picture, there are usually no jaggies along edges because the edge pixels
 are a blend of some foreground and some background. We can get the same effect by averaging a bunch
-of samples inside each pixel. We will not bother with stratification, which is controversial, but is
+of samples inside each pixel. We will not bother with stratification. This is controversial, but is
 usual for my programs. For some ray tracers it is critical, but the kind of general one we are
-writing doesn’t benefit very much from it, and it makes the code uglier. We abstract the camera
-class a bit so we can make a cooler camera later.
+writing doesn’t benefit very much from it and it makes the code uglier. We abstract the camera class
+a bit so we can make a cooler camera later.
 
 One thing we need is a random number generator that returns real random numbers. We need a function
 that returns a canonical random number which by convention returns random real in the range
@@ -1384,7 +1385,7 @@
 ideal diffuse surfaces. (I used to do it as a lazy hack that approximates mathematically ideal
 Lambertian.)
 
-(Reader Vassillen Chizhov proved that the lazy hack is indeed just a lazy hack, and is inaccurate.
+(Reader Vassillen Chizhov proved that the lazy hack is indeed just a lazy hack and is inaccurate.
 The correct representation of ideal Lambertian isn't much more work, and is presented at the end of
 the chapter.)
 
@@ -1404,7 +1405,7 @@
 <div class='together'>
 We need a way to pick a random point in a unit radius sphere. We’ll use what is usually the easiest
 algorithm: a rejection method. First, pick a random point in the unit cube where x, y, and z all
-range from -1 to +1. Reject this point, and try again if the point is outside the sphere.
+range from -1 to +1. Reject this point and try again if the point is outside the sphere.
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     class vec3 {
@@ -2030,7 +2031,7 @@
 </div>
 
 <div class='together'>
-We can also randomize the reflected direction by using a small sphere, and choosing a new endpoint
+We can also randomize the reflected direction by using a small sphere and choosing a new endpoint
 for the ray:
 
   ![Figure [reflect-fuzzy]: Generating fuzzed reflection rays](../images/fig.reflect-fuzzy.jpg)
@@ -2107,7 +2108,7 @@
 
 Is that right? Glass balls look odd in real life. But no, it isn’t right. The world should be
 flipped upside down and no weird black stuff. I just printed out the ray straight through the middle
-of the image, and it was clearly wrong. That often does the job.
+of the image and it was clearly wrong. That often does the job.
 
 <div class='together'>
 The refraction is described by Snell’s law:
@@ -2222,7 +2223,7 @@
   $$ \frac{1.5}{1.0} \cdot \sin\theta > 1.0 $$
 
 The equality between the two sides of the equation is broken, and a solution cannot exist. If a
-solution does not exist the glass cannot refract, and must reflect the ray:
+solution does not exist, the glass cannot refract, and therefore must reflect the ray:
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     if(etai_over_etat * sin_theta > 1.0) {
@@ -2386,8 +2387,8 @@
 
 <div class='together'>
 An interesting and easy trick with dielectric spheres is to note that if you use a negative radius,
-the geometry is unaffected, but the surface normal points inward, so it can be used as a bubble
-to make a hollow glass sphere:
+the geometry is unaffected, but the surface normal points inward. This can be used as a bubble to
+make a hollow glass sphere:
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     world.add(make_shared<sphere>(vec3(0,0,-1), 0.5, make_shared<lambertian>(vec3(0.1, 0.2, 0.5))));
@@ -2507,7 +2508,7 @@
 
 Remember that `vup`, `v`, and `w` are all in the same plane. Note that, like before when our fixed
 camera faced -Z, our arbitrary view camera faces -w. And keep in mind that we can -- but we don’t
-have to -- use world up (0,1,0) to specify vup. This is convenient, and will naturally keep your
+have to -- use world up (0,1,0) to specify vup. This is convenient and will naturally keep your
 camera horizontally level until you decide to experiment with crazy camera angles.
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
@@ -2606,9 +2607,9 @@
 
 <div class="together">
 A real camera has a complicated compound lens. For our code we could simulate the order: sensor,
-then lens, then aperture. Then we could figure out where to send the rays, and flip the image once
-computed (the image is projected upside down on the film). Graphics people usually use a thin lens
-approximation:
+then lens, then aperture. Then we could figure out where to send the rays, and flip the image after
+it's computed (the image is projected upside down on the film). Graphics people, however, usually
+use a thin lens approximation:
 
   ![Figure [cam-lens]: Camera lens model](../images/fig.cam-lens.jpg)
 
@@ -2803,8 +2804,8 @@
 </div>
 
 An interesting thing you might note is the glass balls don’t really have shadows which makes them
-look like they are floating. This is not a bug (you don’t see glass balls much in real life, where
-they also look a bit strange, and indeed seem to float on cloudy days). A point on the big sphere
+look like they are floating. This is not a bug -- you don’t see glass balls much in real life, where
+they also look a bit strange, and indeed seem to float on cloudy days. A point on the big sphere
 under a glass ball still has lots of light hitting it because the sky is re-ordered rather than
 blocked.
 

books/RayTracingTheNextWeek.html

@@ -51,10 +51,10 @@
 average answer with a ray that is at exactly a single time. This is fundamentally why random ray
 tracing tends to be simple.
 
-The basic idea is to generate rays at random times while the shutter is open, and intersect the
-model at that one time. The way it is usually done is to have the camera move and the objects move,
-but have each ray exist at exactly one time. This way the “engine” of the ray tracer can just make
-sure the objects are where they need to be for the ray, and the intersection guts don’t change much.
+The basic idea is to generate rays at random times while the shutter is open and intersect the model
+at that one time. The way it is usually done is to have the camera move and the objects move, but
+have each ray exist at exactly one time. This way the “engine” of the ray tracer can just make sure
+the objects are where they need to be for the ray, and the intersection guts don’t change much.
 
 <div class='together'>
 For this we will first need to have a ray store the time it exists at:
@@ -188,10 +188,10 @@
     [Listing [moving-sphere]: <kbd>[moving_sphere.h]</kbd> A moving sphere]
 
 <div class='together'>
-An alternative to making a new moving sphere class is to just make them all move, and have the
-stationary ones have the same begin and end point. I’m on the fence about that trade-off between
-fewer classes and more efficient stationary spheres, so let your design taste guide you. The
-intersection code barely needs a change: `center` just needs to become a function `center(time)`:
+An alternative to making a new moving sphere class is to just make them all move, while stationary
+spheres have the same begin and end position. I’m on the fence about that trade-off between fewer
+classes and more efficient stationary spheres, so let your design taste guide you. The intersection
+code barely needs a change: `center` just needs to become a function `center(time)`:
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     bool moving_sphere::hit(
@@ -266,9 +266,9 @@
 
 <div class='together'>
 The code below takes the example diffuse spheres from the scene at the end of the last book, and
-makes them move during the image render. (Think of a camera with shutter opening at time 0, and then
-closing again at time 1.) Each sphere moves from its center $\mathbf{C}$ at time $t=0$ to
-$\mathbf{C} + (0, r/2, 0)$ at time $t=1$, where $r$ is a random number in $[0,1)$:
+makes them move during the image render. (Think of a camera with shutter opening at time 0 and
+closing at time 1.) Each sphere moves from its center $\mathbf{C}$ at time $t=0$ to $\mathbf{C} +
+(0, r/2, 0)$ at time $t=1$, where $r$ is a random number in $[0,1)$:
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     hittable_list random_scene() {
@@ -356,8 +356,8 @@
 it a logarithmic search in the spirit of binary search. Because we are sending millions to billions
 of rays on the same model, we can do an analog of sorting the model, and then each ray intersection
 can be a sublinear search. The two most common families of sorting are to 1) divide the space, and
-2) divide the objects. The latter is usually much easier to code up, and just as fast to run for
-most models.
+2) divide the objects. The latter is usually much easier to code up and just as fast to run for most
+models.
 
 <div class='together'>
 The key idea of a bounding volume over a set of primitives is to find a volume that fully encloses
@@ -541,7 +541,7 @@
 If there are any `NaN`s running around there, the compare will return false so we need to be sure
 our bounding boxes have a little padding if we care about grazing cases (and we probably should
 because in a ray tracer all cases come up eventually). With all three dimensions in a loop, and
-passing in the interval $t_{min}$, $t_{max}$ we get:
+passing in the interval $[t_{min}$, $t_{max}]$, we get:
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     #include "rtweekend.h"
@@ -580,9 +580,9 @@
 `NaN`s and other exceptions.
 
 <div class='together'>
-In reviewing this intersection method, Andrew Kensler at Pixar tried some experiments, and has
-proposed this version of the code which works extremely well on many compilers, and I have adopted
-it as my go-to method:
+In reviewing this intersection method, Andrew Kensler at Pixar tried some experiments and proposed
+the following version of the code. It works extremely well on many compilers, and I have adopted it
+as my go-to method:
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     inline bool aabb::hit(const ray& r, double tmin, double tmax) const {
@@ -607,8 +607,8 @@
 We now need to add a function to compute the bounding boxes of all the hittables. Then we will make
 a hierarchy of boxes over all the primitives, and the individual primitives--like spheres--will live
 at the leaves. That function returns a bool because not all primitives have bounding boxes (_e.g._,
-infinite planes). In addition, objects move so it takes `time1` and `time2` for the interval of the
-frame, and the bounding box will bound the object moving through that interval.
+infinite planes). In addition, moving objects will have a bounding box that encloses the object for
+the entire time interval [`time1`,`time2`].
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     class hittable {
@@ -2114,7 +2114,7 @@
 </div>
 
 <div class='together'>
-This is very noisy because the light is small, but we have a problem: some of the walls are facing
+This is very noisy because the light is small. But we have a problem: some of the walls are facing
 the wrong way. We haven't specified that a diffuse material should behave differently on different
 faces of the object, but what if the Cornell box had a different pattern on the inside and outside
 walls? The rectangle objects are described such that their front faces are always in the