## 15.10. Exercises

**Exercise 15.1:** Generalize the `Image` and `DepthBuffer` implementations into different instances of a single, templated buffer class.

**Exercise 15.2:** Use the equations from Section 7.8.2 to extend your ray tracer to also intersect spheres. A sphere does not define a barycentric coordinate frame or vertex normals. How will you compute the normal to the sphere?

**Exercise 15.3:** Expand the barycentric weight computation that is abstracted in the `bary2D` function so that it appears explicitly within the per-pixel loop. Then lift the computation of expressions that are constant along a row or column outside the corresponding loop. Your resultant code should contain a single division operation within the inner loop.

**Exercise 15.4:** Characterize the asymptotic performance of each algorithm described in Section 15.6. Under what circumstances would each algorithm be preferred, according to this analysis?

**Exercise 15.5:** Consider the “1D rasterization” problem of coloring the pixel centers (say, at integer locations) covered by a line segment lying on the real number line.

- What is the longest a segment can be while covering no pixel centers? Draw the number line and it should be obvious.
- If we rasterize by snapping vertices at real locations to the nearest integer locations, how does that affect your answer to the previous question?
(Hint: Nothing wider than 0.5 pixels can now hide between two pixel centers.)

- If we rasterize in fixed point with 8-bit subpixel precision and snap vertices to that grid before rasterization, how does that affect your answer? (Hint: Pixel centers are now spaced every 256 units.)

**Exercise 15.6:** Say that we transform the final scene for our ray tracer by moving the teapot 10 cm and ground to the right by adding 10 cm to the *x*-ordinate of each vertex. We could also accomplish this by leaving the teapot in the original position and instead transforming the ray origins to the left by 10 cm. This is the Coordinate-System/Basis principle. Now, consider the case where we wish to render 1000 teapots with identical geometry but different positions and orientations. Describe how to modify your ray tracer to represent this scene without explicitly storing 1000 copies of the teapot geometry, and how to trace that scene representation. (This idea is called **instancing.**)

**Exercise 15.7:** One way to model scenes is with **constructive solid geometry** or **CSG:** building solid primitives like balls, filled cubes, etc., transformed and combined by boolean operations. For instance, one might take two unit spheres, one at the origin and one translated to (1. 7, 0, 0), and declare their intersection to be a “lens” shape, or their union to be a representation of a hydrogen molecule. If the shapes are defined by meshes representing their boundaries, finding a mesh representation of the union, intersection, or difference (everything in shape *A* that’s *npt* in shape *B*) can be complex and costly. For ray casting, things are simpler.

(a) Show that if *a* and *b* are the intervals where the ray *R* intersects objects *A* and *B*, then *acupb* is where *R* intersects *A ∩ B*; show similar statements for the intersection and difference.

(b) Suppose a CSG representation of a scene is described by a tree (where edges are transformations, leaves are primitives, and nodes are CSG operations like union, intersection, and difference); sketch a ray-intersect-CSG-tree algorithm. Note: Despite the simplicity of the ideas suggested in this exercise, the speedups offered by bounding-volume hierarchies described in Chapter 37 favor their use, at least for complex scenes.