Physically Based Rendering

From Theory to Implementation

Matt Pharr, Greg Humphreys

• Editorial: Morgan Kaufmann
• Año: 2004
• ISBN:
  9780123785800
• Edición: 2
• Categoría: Ciencia de la computación
• Categoría: Gráficos computacionales

Physically Based Rendering, Second Edition, describes both the mathematical theory behind a modern photorealistic rendering system as well as its practical implementation.

A method known as literate programming combines human-readable documentation and source code into a single reference that is specifically designed to aid comprehension. The result is a stunning achievement in graphics education. Through the ideas and software in this book, you will learn to design and employ a full-featured rendering system for creating stunning imagery.

This new edition greatly refines its best-selling predecessor by streamlining all obsolete code as well as adding sections on parallel rendering and system design; animating transformations; multispectral rendering; realistic lens systems; blue noise and adaptive sampling patterns and reconstruction; measured BRDFs; and instant global illumination, as well as subsurface and multiple-scattering integrators.

These updates reflect the current state-of-the-art technology, and along with the lucid pairing of text and code, ensure the book's leading position as a reference text for those working with images, whether it is for film, video, photography, digital design, visualization, or gaming.

• The book that won its authors a 2014 Academy Award for Scientific and Technical Achievement from the Academy of Motion Picture Arts and Sciences
• New sections on subsurface scattering, Metropolis light transport, precomputed light transport, multispectral rendering, and much more
• Includes a companion site complete with source code for the rendering system described in the book, with support for Windows, OS X, and Linux: visit www.pbrt.org
• Code and text are tightly woven together through a unique indexing feature that lists each function, variable, and method on the page that they are first described

Chapter One Introduction

Rendering is the process of producing a 2D image from a description of a 3D scene. Obviously, this is a very broad task, and there are many ways to approach it. Physically based techniques attempt to simulate reality; that is, they use principles of physics to model the interaction of light and matter. In physically based rendering, realism is usually the primary goal. This approach is in contrast to interactive rendering, which sacrifices realism for high performance and low latency, or nonphotorealistic rendering, which strives for artistic freedom and expressiveness.

This book describes pbrt, a physically based rendering system based on the ray-tracing algorithm. Most computer graphics books present algorithms and theory, sometimes combined with snippets of code. In contrast, this book couples the theory with a complete implementation of a fully functional rendering system. The source code to the system (as well as example scenes and a collection of data for rendering) can be found from the pbrt Web site’s downloads page, pbrt.org/downloads.php.

1.1 LITERATE PROGRAMMING

While writing the TEX typesetting system, Donald Knuth developed a new programming methodology based on the simple but revolutionary idea that programs should be written more for people’s consumption than for computers’ consumption. He named this methodology literate programming. This book (including the chapter you’re reading now) is a long literate program. This means that in the course of reading this book, you will read the full implementation of the pbrt rendering system, not just a high-level description of it.

Literate programs are written in a metalanguage that mixes a document formatting language (e.g., TEX or HTML) and a programming language (e.g., C++). Two separate systems process the program: a “weaver” that transforms the literate program into a document suitable for typesetting, and a “tangler” that produces source code suitable

for compilation. Our literate programming system is homegrown, but it was heavily influenced by Norman Ramsey’s noweb system.

The literate programming metalanguage provides two important features. The first is the ability to mix prose with source code. This feature makes the description of the program just as important as its actual source code, encouraging careful design and documentation. Second, the language provides mechanisms for presenting the program code to the reader in an entirely different order than it is supplied to the compiler. Thus, the program can be described in a logical manner. Each named block of code is called a fragment, and each fragment can refer to other fragments by name.

As a simple example, consider a function InitGlobals() that is responsible for initializing all of a program’s global variables:¹

Despite its brevity, this function is hard to understand without any context. Why, for example, can the variable num_marbles take on floating-point values? Just looking at the code, one would need to search through the entire program to see where each variable is declared and how it is used in order to understand its purpose and the meanings of its legal values. Although this structuring of the system is fine for a compiler, a human reader would much rather see the initialization code for each variable presented separately, near the code that actually declares and uses the variable.

In a literate program, one can instead write InitGlobals() like this:

This defines a fragment, called

Function Definitions

, that contains the definition of the InitGlobals() function. The InitGlobals() function itself refers to another fragment,

Initialize Global Variables

. Because the initialization fragment has not yet been defined, we don’t know anything about this function except that it will contain assignments to global variables. This is just the right level of abstraction for now, since no variables have been declared yet. When we introduce the global variable shoe_size somewhere later in the program, we can then write Here we have started to define the contents of

Initialize Global Variables

. When the literate program is tangled into source code for compilation, the literate programming system will substitute the code shoe_size = 13; inside the definition of the InitGlobals() function. Later in the text, we may define another global variable, dielectric, and we can append its initialization to the fragment:

The +≡ symbol after the fragment name shows that we have added to a previously defined fragment. When tangled, the result of these three fragments is the code

In this way, we can decompose complex functions into logically distinct parts, making them much easier to understand. For example, we can write a complicated function as a series of fragments:

Again, the contents of each fragment are expanded inline in complex_func() for compilation. In the document, we can introduce each fragment and its implementation in turn. This decomposition lets us present code a few lines at a time, making it easier to understand. Another advantage of this style of programming is that by separating the function into logical fragments, each with a single and well-delineated purpose, each one can then be written and verified independently. In general, we will try to make each fragment less than 10 lines long.

In some sense, the literate programming system is just an enhanced macro substitution package tuned to the task of rearranging program source code. This may seem like a trivial change, but in fact literate programming is quite different from other ways of structuring software systems.

1.1.1 INDEXING AND CROSS-REFERENCING

The following features are designed to make the text easier to navigate. Indices in the page margins give page numbers where the functions, variables, and methods used on that page are defined. Indices at the end of the book collect all of these identifiers so that it’s possible to find definitions by name. Appendix C, “Index of Fragments,” lists the pages where each fragment is defined and the pages where it is used. Within the text, a defined fragment name is followed by a list of page numbers on which that fragment is used. For example, a hypothetical fragment definition such as

indicates that this fragment is used on pages 184 and 690. If the fragments that use this fragment are not included in the book text, no page numbers will be listed. When a fragment is used inside another fragment, the page number on which it is first defined appears after the fragment name. For example,

indicates that the

Do something else interesting

fragment is defi...