Final text to accompany animation changes

Resolves #799

Author: hollasch

books/RayTracingTheNextWeek.html

@@ -39,28 +39,27 @@
 
 Motion Blur
 ====================================================================================================
-When you decided to ray trace, you decided that visual quality was worth more than run-time. In your
-fuzzy reflection and defocus blur you needed multiple samples per pixel. Once you have taken a step
-down that road, the good news is that almost all effects can be brute-forced. Motion blur is
-certainly one of those. In a real camera, the shutter opens and stays open for a time interval, and
-the camera and objects may move during that time. Its really an average of what the camera sees over
-that interval that we want.
+When you decided to ray trace, you decided that visual quality was worth more than run-time. When
+rendering fuzzy reflection and defocus blur, we used multiple samples per pixel. Once you have taken
+a step down that road, the good news is that almost _all_ effects can be similarly brute-forced.
+Motion blur is certainly one of those.
+
+In a real camera, the shutter remains open for a short time interval, during which the camera and
+objects in the world may move. To accurately reproduce such a camera shot, we seek an average of
+all the instant images that the camera perceives while its shutter is open to the world.
 
 
 Introduction of SpaceTime Ray Tracing
 --------------------------------------
-We can get a random estimate by sending each ray at some random time when the shutter is open. As
-long as the objects are where they should be at that time, we can get the right 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.
+We can get a random estimate of a single photon by sending a single ray at some random instant in
+time when the shutter is open. As long as the objects are where they should be at that instant, we
+can get an accurate measure of the light for that ray at that same instant. This is yet another
+example of how random (Monte Carlo) ray tracing ends up being quite simple. Brute force wins again!
 
 <div class='together'>
-For this we will first need to have a ray store the time it exists at:
+Since the “engine” of the ray tracer can just make sure the objects are where they need to be for
+each ray, the intersection guts don’t change much. To accomplish this, we need to store the exact
+time for each ray:
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     class ray {
@@ -82,7 +81,7 @@
             return orig + t*dir;
         }
 
-      public:
+      private:
         point3 orig;
         vec3 dir;
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++ highlight
@@ -94,10 +93,35 @@
 </div>
 
 
+Managing Time
+--------------
+Before continuing, let's think about time, and how we might manage it across one or more renders.
+There are two aspects of shutter timing to think about: the time from one shutter opening to the
+next shutter opening, and how long the shutter stays open for each frame. Standard movie film used
+to be shot at 24 frames per second. Modern digital films can be 30 or even 60 frames per second.
+Each frame can have its own shutter speed, which need not be -- and typically isn't -- the maximum
+duration of the entire shutter period. You could have the shutter open for 1/1000th of a second per
+frame, or 1/60th of a second. It may surprise you to learn that for most film motion pictures, the
+screen is actually dark more than it is lit up with the movie frames!
+
+If you wanted to render a sequence of images, you would need to set up the camera with the
+appropriate shutter timings: frame-to-frame period, shutter/render duration, and the total number of
+frames (or total shot time). If the camera is moving and the world is static, you're good to go.
+However, if anything in the world is moving, you would need to add a method to `hittable` to
+broadcast the current shot timing to every object in the world. This method would then provide a way
+for all animate objects to set up their motion during that frame.
+
+This is fairly straight-forward, and definitely a fun avenue for you to experiment with if you wish.
+However, for our purposes right now, we're going to proceed with a drastically simplified model. We
+will be render only a single frame, assuming a start at time = 0 and ending at time = 1. Our first
+task is to modify the camera to launch rays with random times in $[0,1]$, and our second task will
+be the creation of an animate sphere class.
+
+
 Updating the Camera to Simulate Motion Blur
 --------------------------------------------
-Now we need to modify the camera to generate rays at a random time between the start time and the
-end time. Should the camera keep track of the time interval, or should that be up to the user of
+We need to modify the camera to generate rays at a random instant between the start time and the end
+time. Should the camera keep track of the time interval, or should that be up to the user of the
 camera when a ray is created? When in doubt, I like to make constructors complicated if it makes
 calls simple, so I will make the camera keep track, but that’s a personal preference. Not many
 changes are needed to camera because for now it is not allowed to move; it just sends out rays over
@@ -130,9 +154,9 @@
 
 Adding Moving Spheres
 ----------------------
-We also need a moving object. I’ll create a sphere class that has its center move linearly from
-`center0` at `time_start` to `center1` at `time_end`. Outside that time interval it continues on, so
-those times need not match up with the camera aperture open and close.
+Now to create a moving object. I’ll create a sphere class that has its center move linearly from
+`center0` at time 0 to `center1` at time 1. (It continues on outside that time interval, so it
+really can be sampled at any time.)
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     #ifndef MOVING_SPHERE_H
@@ -147,17 +171,10 @@
         moving_sphere() {}
         moving_sphere(point3 c0, point3 c1, double r, shared_ptr<material> m)
           : center0(c0), center1(c1), center_vec(c1 - c0), radius(r), mat_ptr(m)
-        {
-            // To Be Implemented
-        };
+        { };
 
         bool hit(const ray& r, interval ray_t, hit_record& rec) const override {
-            // To Be Implemented
-        }
-
-        bool bounding_box(aabb& output_box) const override {
-            output_box = bbox;
-            return true;
+            // Implementation below.
         }
 
         point3 center(double time) const {
@@ -171,7 +188,6 @@
         vec3 center_vec;
         double radius;
         shared_ptr<material> mat_ptr;
-        aabb bbox;
     };
 
     #endif
@@ -226,7 +242,7 @@
     [Listing [moving-sphere-hit]: <kbd>[moving_sphere.h]</kbd> Moving sphere hit function]
 </div>
 
-We need to implement the `interval::contains()` method mentioned above:
+We need to implement the new `interval::contains()` method mentioned above:
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     class interval {
@@ -305,9 +321,8 @@
 ----------------------------
 <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
-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)$:
+makes them move during the image render. Each sphere moves from its center $\mathbf{C}$ at time
+$t=0$ to $\mathbf{C} + (0, r/2, 0)$ at time $t=1$:
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     ...
@@ -725,7 +740,8 @@
 </div>
 
 <div class='together'>
-For `moving sphere`, we can take the box of the sphere at $t_0$, and the box of the sphere at $t_1$,
+For `moving sphere`, we want the bounds of all places the moving sphere could occupy while it moves.
+To do this, we can take the box of the sphere at time = 0, and the box of the sphere at time = 1,
 and compute the box of those two boxes. We'll add a new `aabb` constructor that takes two boxes as
 input below.
 
@@ -739,6 +755,7 @@
     class moving_sphere : public hittable {
       public:
         ...
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++ highlight
         moving_sphere(point3 c0, point3 c1, double r, shared_ptr<material> m)
           : center0(c0), center1(c1), center_vec(c1 - c0), radius(r), mat_ptr(m)
         {
@@ -747,16 +764,28 @@
             const aabb box1(center1 - rvec, center1 + rvec);
             bbox = aabb(box0, box1);
         };
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
 
         ...
 
+
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++ highlight
         bool bounding_box(aabb& output_box) const override {
             output_box = bbox;
             return true;
         }
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
+
         ...
+
+      public:
+        point3 center0, center1;
+        vec3 center_vec;
+        double radius;
+        shared_ptr<material> mat_ptr;
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++ highlight
+        aabb bbox;
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     };
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [Listing [moving-sphere-bbox]: <kbd>[moving_sphere.h]</kbd> Moving sphere with bounding box]
@@ -1241,8 +1270,6 @@
 
         scene_desc.cam.vup = vec3(0,1,0);
         scene_desc.cam.focus_dist = 10.0;
-        scene_desc.cam.time_start = 0;
-        scene_desc.cam.time_end = 1;
 
         switch (0) {
             case 1:  random_spheres(scene_desc); break;
@@ -2350,8 +2377,6 @@
 
         scene_desc.cam.vup = vec3(0,1,0);
         scene_desc.cam.focus_dist = 10.0;
-        scene_desc.cam.time_start = 0;
-        scene_desc.cam.time_end = 1;
 
         ...
     }
@@ -3275,7 +3300,7 @@
         auto center1 = point3(400, 400, 200);
         auto center2 = center1 + vec3(30,0,0);
         auto moving_sphere_material = make_shared<lambertian>(color(0.7, 0.3, 0.1));
-        world.add(make_shared<moving_sphere>(center1, center2, 50, moving_sphere_material, 0, 1));
+        world.add(make_shared<moving_sphere>(center1, center2, 50, moving_sphere_material));
 
         world.add(make_shared<sphere>(point3(260, 150, 45), 50, make_shared<dielectric>(1.5)));
         world.add(make_shared<sphere>(