Ray Tracing from the Ground Up

Kevin Suffern

• Publisher: A K Peters/CRC Press
• Year: 2016
• ISBN:
  9781498774703
• Edition: 1
• Topic: Computer Science
• Subtopic: Computer Graphics
• Index: Computer Science

With the increase in computing speed and due to the high quality of the optical effects it achieves, ray tracing is becoming a popular choice for interactive and animated rendering. This book takes readers through the whole process of building a modern ray tracer from scratch in C++. All concepts and processes are explained in detail with the aid o

1 Ray Tracer Design and Programming

• 1.1 General Approaches
• 1.2 Inheritance
• 1.3 Language
• 1.4 Building Scenes
• 1.5 The User Interface
• 1.6 Skeleton Ray Tracer
• 1.7 Developing the Ray Tracer
• 1.8 Floats or Doubles
• 1.9 Efficiency Issues
• 1.10 Coding Style
• 1.11 Debugging

Image courtesy of Jimmy Nguyen Skeleton model from Clemson University

A ray tracer with any reasonable set of features is a large and complex software system that must be designed carefully and developed in a systematic manner. This chapter gives you guidelines for the design and programming of a ray tracer. You can also find information on these topics in Glassner (1989), Wilt (1994), Shirley (2002), Shirley and Morley (2003), and Pharr and Humphreys (2004).

1.1 General Approaches

It’s best to develop your ray tracer using object-oriented (OO) techniques for several reasons. The first is size and complexity. Object-oriented techniques are best for handling the design and implementation of large and complex systems, and ray tracers can certainly be large and complex. One of the largest was the Kilauea ray tracer, which consisted of about 700,000 lines of C++ code (Kato et al., 2001, Kato, 2002). Although the ray tracer I discuss here is not nearly this large, it is large and complex enough for OO techniques to be essential for its development.

The second reason is extensibility, which is not really separate from the first, because large and complex software systems are developed by extending simpler systems. Ray tracers can be extended in many ways, for example, by adding new types of geometric objects. You should design your ray tracer so that adding new types of objects is as simple as possible. OO techniques allow you to do this without altering the existing code that renders the objects. Your ray tracer will also have to deal with different types of cameras, samplers, lights, BRDFs, materials, mappings, textures, noises, and bump maps. Adding a new type of any of these things should also be as simple as possible.

Let’s look at how OO techniques facilitate these processes. The code that performs the ray-object intersections should not have to know the type of objects it deals with. Why? Because it would then have to explicitly identify the type of each object, and intersect it in a case or switch statement. This makes it more work to program because you must provide an identifier for each type, and add a new clause to the switch statement. To make matters worse, the switch statement may have to appear in more than one place in the ray tracer. It’s far better for objects to be anonymous in the intersection part of the ray tracer. To do this you define a uniform public interface for the intersection (hit) functions, so that they are called the same way for all objects. The ray tracer, which can still identify the type of each object at run time, will then call the correct hit function.

You should also apply the same process to lights, materials, textures, etc. Except for build functions and #include statements, your ray tracer should not have to explicitly identify the type of anything that it deals with. From a design and development perspective, this is the most important aspect of your ray tracer code.

Kirk and Arvo (1988) discussed the above issues for the first time in a ray tracing context, including the use of a common user interface for all objects. This was the first paper on object oriented ray tracing; it contains many good ideas.

1.2 Inheritance

The best way to implement the above processes is to use inheritance. Figure 1.1 shows a sample geometric object inheritance chart. Provided you implement the objects correctly, dynamic binding guarantees that the correct hit functions are called. This is called polymorphism.

Figure 1.1 A sample object inheritance chart.

Code re-use is another benefit of inheritance. The fact that derived classes can use all the code in their base classes means that you only have to write the new parts when you add derived classes. For example, the code to handle the material only has to be written once in the GeometricObject class.

1.3 Language

The sample code in this book is C++ because it’s the mainstream ray tracing language. The reasons are: its OO facilities, the ability to mix C and C++ code in the same program, and its computational efficiency. State of the art commercial ray tracers such as Brazil, Mental Ray, finalRender, and Maxwell Render are written in C++. Also, many major commercial rendering and animation packages, which were originally written in C, were re-written from the ground up in C++ during the 1990s. RenderMan plug-ins can also be written in C++.

Computational efficiency is important for ray tracers because of their extensive use of floating point calculations. C++ programs can be written efficiently because of the C heritage of C++, and the fact that they are fully compiled. If you are not careful, however, you can write inefficient C++ programs. The books by Meyers (1996, 2001, 2005), Lippman et al. (2005), and Bulka and Mayhew (2000) discuss computational efficiency in C++. Writing efficient code is, however, not as important as writing code that’s easy to read, easy to maintain, and easy to extend. In other words, efficiency is not as important as good design. Fortunately, the two can go hand in hand in C++. Also, efficiency is not as important as using language features that make your job as a programmer easier. For example, there can be a cost penalty with inheritance in C++ because of the extra indirection of virtual function calls, and because dynamic binding prevents the inlining of virtual functions, but this is far outweighed by the benefits.

C++ can also use the Standard C library functions, and has excellent library facilities of its own, particularly the Standard Template Library (STL). See Lippman et al. (2005), Meyers (2001), and Ford and Topp (2001). C++ also has operator overloading that allows the code for many vector and matrix operations to be written in mathematical-like notation.

Public domain C code, such as code for solving cubic and quartic polynomial equations (Schwarze, 1990), can be simply incorporated into C++ programs, as can the efficient C macros for genera...