Advanced_Renderman_Book[torrents.ru]

Figure 2.14 The gamut of a typical dye sublimation printer is smaller than that of an NTSC RGB monitor, which itself is a subset of all of the visible colors. This plot is a slice of tghe 3D CIEXYZ color space.

ate parent node, not relative to the world coordinate system. Thus, a change to the transformation at a particular node automagically modifies the position of all geometry below that node in the tree without having to modify any of those nodes' specific transformations. This makes modeling complex jointed objects much easier.

This concept of parts with subparts that are generally the same, but which may differ in a minor way relative to the nodes above them, can be expanded to include more than simply the transformations that control their position and orientation. It is quite common for hierarchies of material attributes to be just as useful. For example, the paint color of a small part on a car will generally be the same as the color of the structure above it. Another way of looking at this scheme is that nodes lower in the hierarchy generally inherit their basic characteristics from their parent nodes but can modify them as necessary.

The obvious data structure for manipulating hierarchical trees is a stack. At each node of the tree, the state of the hierarchy is pushed onto the stack for safekeeping. The node is allowed to make whatever modifications to the state that are required to fulfill its purpose and to supply the appropriate state to its child subnodes. When the node is completed, the state stack is popped and thus the state is restored to the state of the parent. Sibling subnodes can then start their processing with the same state that the first subnode had.

50 2 Review of Mathematics and Computer Graphics Concepts

A geometric model can have a variety of different useful hierarchiestransformation hierarchies, attribute hierarchies, illumination hierarchies, dynamics hierarchies, even manufacturer and cost hierarchies. However, complex interrelationships often form data structures more complex than simple tree hierarchies (such as groups or directed graphs), and rendering systems are interested in a small subset of this list anyway. For this reason, RenderMan describes models in terms of a single unified attribute and transformation hierarchy.

2.4.9Shading Models

The process that a renderer uses to determine the colors of the objects in a scene is known as shading. As mentioned in Section 2.3.3, the BRDF of an object, and hence the color of the object as seen from any particular viewpoint, is a complex interaction of light with the microscopic structure of the material at the surface (and sometimes beneath the surface) of the object. Fortunately for computer graphics, it is usually not necessary to model this interaction with exact physical correctness in order to get a good-looking or believable appearance for our images. In fact, a wide variety of materials can be effectively simulated with a small number of approximations that have been developed over the years. The popular approximations to the BRDFs are typically empirical models (based on experiment and observation without relying on scientific theory), although many slightly more complex models exist that are better grounded in materials physics (and these really should be used instead).

Two of computer graphics' most venerable empirical models of light reflection are Lambert shading and Phong lighting, 4 which are illustrated in Figure 2.15. Lambert shading captures the idea of an ideal diffuse reflector, an extremely rough surface. Such an object reflects light equally in all directions. The only difference in the appearance of such an object relates to the angle that it makes with the light source direction. An object that is lit edge-on covers a smaller area as seen from the light source, so it appears dimmer, than an object that presents itself full-on to the light. This difference is captured by the cosine of the illumination angle, which can be computed as the dot product of the surface normal and the light source direction,

Phong lighting simulates the appearance of the bright white spots that are visible on shiny objects. These spots are caused when smooth objects reflect light preferentially in a direction near the reflection direction and are known as specular

4 In 1975, Bui Tuong Phong actually described in a single research paper three related but distinct ideas that are often confused with one another and are rarely given separate names. Phong shading refers to computing the color at every pixel rather than only at the corners of large polygons, Phong interpolation refers to linearly interpolating normal vectors to get the appearance of continuous curvature on the flat polygonal surface, and Phong lighting refers to the popular specular highlight equation he developed. By the way, Phong was his given name, Bui was his surname.

52 2 Review of Mathematics and Computer Graphics Concepts

objects and picking up their color, and eventually strike the film in a camera. This paradigm of following the paths of photons as they meander through a scene is called ray tracing. In practice, ray tracing renderers do not follow rays forward from the light sources in hopes that some of them will eventually make their way to the camera. The vast majority of rays do not, and it would take a long time to render a picture. Instead, ray tracers follow rays backwards from the camera, until they eventually reach a light. (Interestingly, the ancient Greeks believed that what we saw was dependent on where "vision beams" that came out of our eyes landed. Modern physicists say that the simulation result is the same because a path of light is reversible-light can go equally well in both directions and follows the same path either way.)

Because ray tracing simulates the propagation of light, it is capable of creating realistic images with many interesting and subtle effects. For example, reflections in a mirror and refractions through glass are very simple because they require only minor changes to the ray path that are easily calculated with the reflection and refraction laws discussed earlier. Techniques have been developed to simulate a variety of optical effects, such as fuzzy reflections (reflections in rough surfaces where the image is blurred because the reflected rays don't all go in the same direction) and participating media (also known as volumetric) effects (light interacts with a material that it is passing through, such as scattering off smoke in the air). One of the most interesting of these effects is the caustic, the phenomenon of light being focused by the reflective and refractive objects in the scene, which causes bright (or dark) spots on objects nearby, such as on the table under a wine glass.

The fundamental operation of a ray tracing algorithm is finding the intersection of a line with a geometric object. The semi-infinite line represents the ray of light. (We use a "semi-infinite" line because we are interested only in that region of the line in front of the ray's origin, not behind it.) If several objects intersect the ray, the desired intersection is the one that is closest to the origin of the ray. Depending on the type of geometric primitive (sphere, polygon, NURBS, and so on), anything from a simple mathematical equation to a complex geometric approximation algorithm may be necessary to calculate the intersection of the ray with that primitive type. Practical ray tracers have elaborate algorithms for trivially rejecting objects that are nowhere near the ray, in order to economize on expensive intersection calculations. The process of intersecting a single ray with a set of geometric primitives is properly known as ray casting. Ray tracing properly refers to the technique of recursively casting reflection, refraction, or other secondary rays from the point of intersection of the primary ray, in order to follow the path of light as it bounces through the scene.

It is not uncommon for renderers that do not use ray tracing as their basic algorithm to nonetheless require the occasional intersection of a ray with a single or a few geometric objects. In common usage, the phrases "trace a ray" or "cast a ray" are used to describe any such intersection calculation.

2.4.1 1 Other Hidden-Surface Algorithms

Because ray tracing is intuitive and captures a wide variety of interesting optical effects, it is one of the most common ways to write a renderer. In some circles, the terms ray tracing and rendering are naively used synonymously. However, ray tracing is a computationally expensive process, and there are other image synthesis algorithms that take computational shortcuts in order to reduce the overall rendering time.

One of the main operations that a renderer performs is to determine which objects are visible in the scene and which objects are hidden behind other objects. This is called hidden-surface elimination. Many algorithms exist that examine the objects in the scene and determine which are visible from a single point in the scene-the camera location. Scanline, z-buffer, and REYES algorithms are examples of these. Objects are typically sorted in three dimensions: their x and y positions when projected onto the camera's viewing plane and their z distance from the camera. The differences among the many algorithms are based on factors such as the order of the sorting, the data structures that are used to maintain the geometric database, the types of primitives that can be handled, and the way that the hiddensurface algorithm is interleaved with the other calculations that the renderer needs to do (such as shading) to create the final image.

The primary computational advantage of these algorithms is that they only handle each object in the scene once. If it is visible from the camera, it is only visible at one location on the screen and from that one angle. It cannot appear in other parts of the screen at different angles or at different magnifications. Once an object has been rendered, it can be discarded. If it is not visible in a direct line of sight from the camera, it can be discarded up front, as there is no other way to see it. Ray tracers, on the other hand, must keep all of the objects in the scene in memory for the entire rendering, as mirrors or a complex arrangement of lenses in the image can cause any object to appear multiple times in the scene at different sizes and from different angles.

Notice, however, that because these hidden-surface algorithms compute visibility only from a single point, it is not generally possible to calculate information about what other points in the scene can see, such as would be necessary to do true reflection and refraction calculations. We lose the ability to simulate these optical effects. Ray tracing, on the other hand, keeps the data structures necessary to generate visibility information from between any two points in the scene. For this reason, we say that ray tracing is a global visibility

algorithm, and lighting calculations that make use of this facility are called global illumination calculations. Renderers without global visibility capabilities must simulate global illumination effects with tricks, such as texture maps that contain images of the scene as viewed from other angles.

54 2 Review of Mathematics and Computer Graphics Concepts

Further Reading

There are any number of great textbooks on math, physics, and computer graphics, and to leave any of them out would be a disservice to their authors. However, we aren't the Library of Congress index, so we'll pick just a handful that we find useful, informative, and easy to read. If we left out your favorite (or the one you wrote!), we apologize profusely.

For a very gentle introduction to mathematics as it applies to computer graphics, we've recently discovered Computer Graphics: Mathematical First Steps by Egerton and Hall. The next step up is Mathematical Elements for Computer Graphics by Rogers and Adams, but be comfortable with matrix math before you dig in. For those wanting to brush up on the calculus, Martin Gardner's rewrite of Thompson's classic text

praise from everyone who reads it.

On basic physics and optics, the one on our shelves is still Halliday and Resnick's Fundamentals of Physics, now in its fifth edition and still a classic. Pricey, though. For a more gentle introduction, it's hard to go wrong with Gonick's Cartoon Guide to Physics. If you're interested in cool optical effects that happen in nature, two of the best books you'll ever find are Mirmaert's Light and Color in the Outdoors and Lynch and Livingston's Color and Light in Nature.

Modern computer graphics algorithms are not well covered in most firstsemester textbooks, so we recommend going straight to Watt and Watt, Advanced Animation and Rendering Techniques. It's diving into the deep end, but at least it doesn't burn 50 pages on 2D line clipping algorithms, and it gets bonus points for mentioning RenderMan in one (short) chapter.

Describing Models

and Scenes in

RenderMan

RenderMan is divided into two distinct but complementary sections: scene modeling and appearance modeling. The placement and characteristics of objects, lights, and cameras in a scene, as well as the parameters of the image to be generated, are described to a RenderMan renderer through the RenderMan Interface. The details of the appearance for those objects and lights are described to a RenderMan renderer through the RenderMan Shading Language.

3.1 Scene Description API

The RenderMan Interface (RI) is a scene description API. API stands for "Applications Programming Interface," but what it really means is the set of data types and function calls that are used to transmit data from one part of a system to anotherin this case, from a "modeler" to the "renderer."

58 3 Describing Models and Scenes in RenderMan

Users of RenderMan often find themselves initially separated into two camps: users of sophisticated modeling programs that communicate the scene description directly to the renderer and who therefore never see the data, and users who write scene descriptions themselves (either manually or, hopefully, by writing personal, special-purpose modeling programs) and who need to be fluent in the capabilities of RI API. Over time, however, these groups tend to blend, as modeler users learn to "supplement" the scene description behind the back of the modeler and thus become RI programmers themselves.

The next two chapters describe the RenderMan Interface API and try to show how it is typically used so that users in both groups will be able to create more powerful customized scene descriptions. It is a summary and will skimp on some of the specific details. Those details can be found in the RenderMan Interface Specification; recent extensions are usually documented extensively in the documentation sets of the RenderMan renderers themselves.

Language Bindings

In computer science parlance, an API can have multiple language bindings-that is, versions of the API that do basically the same tasks but are customized for a particular programming language or programming system. The RenderMan Interface has two official language bindings, one for the C programming language and another that is a metafile format (the RenderMan Interface Bytestream, or RIB). Details of both of these bindings can be found in Appendix C of the RenderMan Interface Specification. Bindings to other programming languages, such as C++, Lisp, Tcl, and recently Java have been suggested, but none have

yet been officially blessed by Pixar.

Early descriptions of the RenderMan interface concentrated on the C binding, because it was felt that most users of the API would actually be the programmers of modeling systems-users would never actually see RI data. The RIB metafile binding was not finalized and published until after the RenderMan Companion had been written, so the Companion unfortunately does not contain any reference to RIB.

We call RIB a metafile format because of its specific nature. Metafiles are datafiles that encode a log of the calls to a procedural API. RIB is not a programming language itself. It does not have any programming structures, like variables or loops. It is simply a transcription of a series of calls to the C API binding into a textual format. In fact, the syntax of RIB was designed to be as close to the C API as possible without being silly about it. For example, the C RenderMan calls to place a sphere might be

RiAttributeBegin ( );

RiTranslate ( 0.0, 14.0, -8.3 );

RiSurface ( "plastic", RI NULL );

RiSphere ( 1.0, -1.0, 1.0, 360.0, RI-NULL

RiAttributeEnd ( );

while the RIB file version of this same sequence would be

AttributeBegin

Translate 0.0 14.0 -8.3

Surface "plastic"

Sphere 1 -1 1 360

AttributeEnd

Every RIB command has the same name (minus the leading Ri) and has parameters of the same types, in the same order. In the few cases where there are some minor differences, it is due to the special situation that C calls are "live" (the modeling program can get return values back from function calls), whereas RIB calls are not. For this reason, examples of RI calls in RIB and in C are equivalent and equally descriptive. In this book, we will present all examples in RIB, because it is generally more compact than C.

RIB has a method for compressing the textual datastream by creating binary tokens for each word, and some renderers also accept RIB that has been compressed with gzi p to squeeze out even more space. We won't worry about those details in this book, as those files are completely equivalent but harder to typeset. Again, see the RenderMan Interface Specification, Appendix C, if you are interested in the particulars.

3.1.2Modeling Paradigm

RenderMan is a rich but straightforward language for describing the objects in a scene. Like other computer graphics APIs (such as PHIGS+, OpenGL, and Java3D), it contains commands to draw graphics primitives in certain places, with certain visual attributes. Unlike those APIs, RenderMan is intended to be a high-level description, in that modeling programs would describe what was to be rendered without having to describe in detail how it was to be rendered. As such, it contains commands for high-level graphics primitives, such as cubic patches and NURBS, and abstract descriptions of visual attributes, such as Shading Language shaders. It was also specifically designed to contain a rich enough scene description that it could be used by photorealistic renderers, such as ray tracers, whereas most other APIs deal specifically with things that can be drawn by current-generation hardware graphics accelerators.

However, the designers also realized that over time, graphics hardware would grow in speed and capability and that eventually features that were once the sole domain of high-end renderers (such as texture mapping, shadows, and radiosity) would eventually be put into hardware. RenderMan was designed to bridge the gap between fast rendering and photorealistic rendering, by considering the constraints of each and removing things that would make it impossible to efficiently do one or the other.