Editing Glome tutorial (section)

===Bounding Objects===
The preceding sections have (hopefully) shown everything you need to know to model the kinds of shapes you want to render.  However, there are many equivalent ways to represent the same scene, and some of them render much faster than others.  To understand why, you will need to know a little bit about how a ray tracer works.

A ray tracer sends rays out from the camera into the scene, one ray per pixel.  (Or more than one ray, if the ray tracer supports anti-aliasing, which GlomeView currently does not.)  Each ray has to be tested for intersection with each object in the scene.  (Conceptually, scenes in Glome are only comprised of a single object, but in practice intersecting with that object usually means doing a lot of ray-intersections with sub-objects.)  For scenes with many objects, this can be very slow.  Supposing we have a thousand spheres in our scene, and at the default resolution of 720x480, we have 345,600 rays.  This means that for each image, we have to do 345.6 million ray-sphere intersection tests!  Hardware may be getting faster, but we need to do better than that if we want anything near reasonable rendering speed.

Fortunately, we don't really need to do that many ray-intersection tests.  What we can do instead is place bounding objects around the complicated bits of our scene.  If a ray doesn't hit the bounding object, then we know it won't hit anything inside the bounding object, and we don't have to do any of those intersection tests.

Glome has a "Bound" primitive just for this purpose: If you have some complicated solid "a" and a simple bounding solid (such as a sphere or a box) "b", you can declare the bounded object as <haskell>Bound b a</haskell> (the simple object comes first).

You could do a similar thing with Intersection, but Bound is a bit more efficient.

Bounding objects are great for improving performance, but they're unwieldy.  Finding the smallest bounding object that will enclose another object is a non-trivial task, and it's easy to make mistakes, leading to incorrect renderings.  Also, it is not always obvious whether the overhead introduced by testing against the bounding object is outweighed by the reduced number of intersections against the bounded object.