Advanced_Renderman_Book[torrents.ru]

1 Photosurrealism

to slight imperfections. Refraction is handled similarly, using an environment map indexed by the refracted ray direction, and here the fudging of object thickness causes the largest imperfections.

Experience has shown that viewers have so little intuition about the reflection situation that almost any approximation will do. Only glaring artifacts, such as constant-colored reflections, inconsistency from frame to frame, or the failure of mirrors to reflect objects that touch them, will generally be noticed. In fact, experience has shown that viewers have so very, very little intuition about the reflection situation that wildly and even comically inaccurate reflections are perfectly acceptable. For example, it is common for production studios to have a small portfolio of "standard reflection images" (such as someone's house or a distorted photo of someone's face) that they apply to all objects that are not perfect mirrors.

This insensitivity to nonphysical optics gives rise to possibilities for storytelling. The objects that are actually visible in a reflection, the intensity and blurriness of the reflection of each object, and the size and location of the reflection of each object are all generally controlled independently. In Toy Story, for example, Buzz Lightyear's plastic helmet reflected only three objects of note:

a prerendered image of the room he was in, quite blurry Woody's face when he was near, sharply

the TV set during the commercial, very brightly and sharply

just enough blurry room reflection was present to give Buzz the appearance of being in the room and to remind the viewer that Buzz's helmet was down, but it is only seen near the periphery, so that it never obscured Buzz's face and lip movements (Figure 1.1). A reflection of Woody was used when the director wanted to emphasize that they were close together and their fates were intertwined. The key reflection of the TV commercial in the helmet was carefully crafted to be large, bright, and sharp, so that the audience could easily watch it, but does not obscure Buzz's crucial facial expression at discovering the truth of his origins (which, of course, marked the turning point of the film).

Even more nonphysically, viewers are generally unaware of the difference between a convex and a concave mirror, to the director's delight. Convex mirrors are generally more common in the world, such as automobile windshields, computer monitors, metal cans, pens, and so on. However, mirrors that magnify are generally more interesting objects cinematographically. They help the director focus attention on some small object, or small detail, onto which it would otherwise be difficult to direct the viewers' attention. Unfortunately for the live-action cinematographer, magnifying mirrors are concave and are extremely difficult to focus. But this is no problem in CGI. Because the reflection is generally a texture map anyway (and even if it is not, the reflected rays are under the control

1.2Altered Reality

Figure 1.1 Toy Story-Buzz Lightyear's helmet reflection is carefully crafted to not obscure his winning features. ((C) Disney Enterprises, Inc.) See also color plate 1.1.

of the technical director), it is quite simple (and even quite common) for a convex (minifying) mirror to have a scaling factor that is not merely arbitrarily independent of its curvature, but actually magnifying-completely inverted from reality.

Similarly, refractions are extremely difficult for viewers to intuit, and they generally accept almost anything as long as it is vaguely similar to the background, distorted, and more so near the silhouette of the refracting object. They typically are blissfully unaware of when a real refraction would generate an inverted image and are certainly unable to discern if the refraction direction is precisely in the right direction. For example, in Pixar's short film Geri's Game (Pixar, 1997), there is a shot where the director asked for Geri to appear innocent and angelic after having just tricked his opponent into losing. This is accomplished by having Geri's eyes magnified large by his glasses, with pupils widely dilated (Figure 1.2). Even careful inspection of the frame by trained professionals fails to expose the fact that the image that we would see through Geri's glasses from this camera angle would not magnify nor frame his eyes this way. (Never mind the fact that he actually has flat lenses.) The refraction is actually zoomed, reoriented, and slightly rotated in order to give the director the image he desired.

1 Photosurrealism

Figure 1.2 Geri's Game-Geri's large eyes give him an angelic appeal. (Cc; Pixar Animation

Studios) See also color plate 1.2.

1.3Production Requirements

Once a production studio has made the choice to use CGI, for an effect or an entire film, it starts to make very specific demands on the rendering software developers. Films are very expensive to make, and a lot is riding on the studio's success in using the renderer. Failure is not an option when tens of millions of dollars are nn the line.

1.3.1Feature Set

The most obvious production requirement is feature set. The studio requires that the renderer do everything they could ever want or need. The features that are required to do a particular film are obviously different from one film to the next, and one year to the next, but there are certain constants.

For example, a production renderer must handle motion blur. One of the easiest ways for a viewer to detect that an object was filmed independently and added to the scene (i.e., an effect) is for the object to strobe when the background blurs. Audiences simply will not accept a return to the days of stop motion.

Production renderers must accept a wide variety of input geometry. It is not enough for the rendering algorithm to have just polygons. NURBS and other para

1.3Production Requirements

metric curved surfaces are standard today, and various fads such as primitives for rendering hair, implicit surfaces, and other special-purpose models must be handled in a timely fashion.

Production renderers must make a wide variety of tricks available to the technical director. Everything from shadows, texture mapping of all varieties, atmospheric and volumetric participating-media effects, depth-of-field, lens flare, and control information for post-rendering compositing and manipulation of images must be provided for.

1.3.2Flexibility

Related, yet perhaps even more important, requirements are flexibility and controllability. The studio requires that the renderer be user-programmable so that it can be made to do everything that no one ever knew would be needed.

For example, every production renderer now contains some sort of shading language (Hanrahan and Lawson, 1990) with which the users can redefine the shading model in almost arbitrary ways. It is hard to overstate how critical this one feature of a renderer is to a production environment. Technical directors will not accept the standard Phong shading model on all objects, no matter how many knobs and dials it has. As we have seen, they must be able, on a detailed object-by-object basis, to change surface properties and material characteristics, reactivity to light, and even the physics of light and optics itself to generate the compelling photosurrealistic image for each shot. The director of a film generally has very little sympathy for limitations of the software environment. They want their image to look a certain way, and the technical directors must find a way to make it happen.

The best proof of flexibility is the use of a renderer for purposes not envisioned by the software developer. For example, "photorealistic" renderers are now commonly used in traditional cel-animation studios to create distinctly nonphotorealistic imagery that blends with artwork. Cartoon realism is very distinct but easily accommodated if the rendering architecture is flexible enough.

Similarly, programmability in other parts of the rendering pipeline is becoming more important. Procedurally defined geometric primitives are coming back into style as data amplification is exploited to increase the visual complexity of images with minimal human work. Reprogrammable hidden-surface algorithms and easy access to other renderer "internal state" are also valuable.

A production renderer also has a powerful set of speed/quality and speed/ memory trade-offs, which are intuitive and easily controllable. Production deadlines often require that compromises be made, and the variety of hardware to which the studios have access (often some of several different generations of hardware) makes it difficult to effectively utilize all available resources when only the "factory settings" are available.

1Photosurrealism

1.3.3Robustness

A key requirement for any large software package is robustness and reliability. A full-length computer-animated feature film has over 100,000 frames to render (and probably many times that number after counting test frames, rerenders for artistic changes, separate elements for compositing, and rendered texture maps), so the technical directors cannot slave over each one individually. A production renderer absolutely cannot crash, must have vanishingly few bugs, and must reliably generate the correct image each and every time it is executed. If the renderer could guess the intentions of the user even when he gave it the wrong input, that would be a requirement, too.

The renderer should, for all practical purposes, have no limits. Arbitrary limits on number of lights, number of texture maps, number of primitives, image resolution, and so on will all be exceeded by production studios in short order.

Moreover, the feature set of the renderer should be orthogonal. If the renderer can do motion blur on spheres and then a new primitive type is implemented, production will require motion blur on the new primitive on day 2. Every feature must interoperate with every other feature, unless it is clearly nonsensical to do so, and perhaps even then.

1.3.4Performance

Another obvious production requirement is performance. Those 100,000 frames have to be computed in a matter of months on machines that the production studio can afford to buy. Movies cost a lot to make, but, in fact, very little of that money is actually allocated to the computer hardware necessary to make the effects. This means that the time to render a frame must be reasonable, the memory used to render the frame must be limited, and the database that holds the scene description must be compact. For this reason alone, global illumination is rarely used in production rendering, because it cannot generally fulfill these requirements.

And the software developers must not count on Moore's laws to solve this problem. While it is true that computers get faster and memory gets cheaper, seemingly without end, there is a countermanding observation that we call Blinn's law, which states that regardless of hardware, all renderings take the same amount of time. As computers get faster, all that happens is that the appetites of the users get greater, and their requirements get more demanding. In some studios, the appetite grows even faster than Moore allows!

Another aspect of performance that is often overlooked is predictability. A technical director should be able to guess, with some accuracy, how long a frame will take to render based on information that they know (such as the number of objects

"Computing power doubles every 18 months."

in the scene, resolution, etc.). Frames that take nonlinearly more time because a small thing was added are unacceptable when the studio is trying to make budgets, allocate resources, and complete work by totally inflexible delivery dates.

1.3.5Image Quality

Perhaps the most subtle, and yet in many ways the most important, production requirement is image quality. Production studios require images of the highest possible quality. Those images are going to be projected onto the big screen, and every bad pixel will be huge and ugly in front of millions of viewers. Artifacts of any and all varieties are to be eliminated with extreme prejudice. High-quality antialiasing in all dimensions, texture and shader filtering, pixel filtering, and accurate geometric approximations are all required features. Polygonal approximation artifacts, patch cracks, intersection mistakes, shadow acne, visible dithering patterns, Mach bands, and any other image-generation errors are unacceptable.

Because these images are going to be used in animations, frame-to-frame consistency is an important but subtle point. Objects that don't move shouldn't shimmer, and objects that move slowly shouldn't pop. Antialiasing of shading, lighting, and geometry must work consistently at all scales and all distances from the camera.

1.4Enter RenderMan

In case it isn't obvious, for the last several pages we've really been talking about our pride and joy, Pixar's PhotoRealistic RenderMan. There are other production renderers available to the film production community, of course, but PRMan is currently the most widely used.

So, just what is RenderMan? The RenderMan Interface is a standard communications protocol between modeling programs and rendering programs capable of producing photorealistic-quality images. Its goal is to provide a standard mechanism for modeling and animation software to send data to rendering systems in a device-independent way and with minimal regard to the actual rendering algorithms being used. In this way, RenderMan is similar to PostScriptTM, but for 3D primitives. By creating input for a RenderMan-compliant renderer, you and your modeling or animation system can concentrate on making a beautiful image, largely without concern for the details of the exact rendering methods used. A particular RenderMan implementation may use scanline methods (z-buffer, REYES), ray tracing, radiosity, or other methods (and indeed, implementations exist that support all of these). Because RenderMan's capabilities were designed for the very high end of animation production, you can be assured that nearly any fully compliant renderer will produce output of outstanding quality.

1 Photosurrealism

The RenderMan Interface specifies an ambitious list of features for compliant renderers, including a complete hierarchical graphics state, high-quality pixel filtering and antialiasing, a programmable Shading Language for describing lights and surfaces, and support of a wide array of high-level ,geometric primitives, including quadrics, bicubic patch meshes, and trimmed NURBS. In addition, RenderMancompliant renderers may support CSG, level of detail, various types of texture mapping (including reflection, environment, shadow, and displacement mapping), motion blur, depth-of-field, volume shading, ray tracing, area lights, and radiosity effects. Many of these features are very advanced, and some rendering algorithms simply cannot support certain features, so the availability will tend to vary from implementation to implementation.

Pixar developed and published the RenderMan Interface Specification in 1988, with the goal that it would contain enough descriptive power to accommodate advances in modeling, animation, and rendering technologies for several years. It has done a remarkably good job, and even after 11 years, it is still the only open specification for scene description that includes concepts such as motion blur and user-definable appearance characteristics. This means that RenderMan renderers will generate very high-quality images, both in their simulation of objects in their environment and in their simulation of the camera.

Of course, the past 11 years have seen a lot of changes as well. The original dream that the RenderMan Interface would be an open standard that all renderer vendors would embrace, giving the industry a family of compatible renderers that each excelled at different effects, quite simply never came to pass. Instead, the name "RenderMan" colloquially came to refer only to Pixar's PhotoRealistic RenderMan product (referred to in this book as PRMan), and "RenderMan compatibility" came to mean being compatible with PRMan. Once it became clear that RenderMan was destined to be a proprietary interface after all, strict "standards conformance" was abandoned, and since then many new and very interesting features have been added to the RenderMan renderers that greatly increase their power and utility.

The result of this strength, both the strength of the specification and the strength of the flagship renderer that carries its name, is that studios throughout the world have made RenderMan their rendering platform of choice for doing work that demands images of the highest quality. Most visibly, major players in the motion picture industry have chosen RenderMan to generate 3D computer graphics special effects for films as diverse as Jurassic Park, Mulan, and, of course, A Bug's Life. The striking results that these and other films have achieved through the use of RenderMan is why we are writing this book.

Of course, nowadays more than one implementation of RenderMan is available. The most robust and widely used is still Pixar's PRMan product, of course. Another popular implementation is Blue Moon Rendering Tools' rendrib (referred to in this book as BMRT), which provides both a ray tracing/radiosity hybrid renderer and a fast previewer that runs atop OpenGL. Other vendors have, at various times, announced their own RenderMan-compatible renderers. The widespread availability of many different RenderMan renderers, with different algorithms, speed/quality

1.5 Sign Me Up!

trade-offs, and special capabilities, and yet with a consistent file format, API, and Shading Language, will

make it ever more valuable to be fluent with RenderMan.

1.5 Sign Me Up!

How should a new technical director learn to use RenderMan? How should an experienced TD keep up-to-date on the state-of-the-art tricks? How should writers of competitive renderers (yes, we know you're out there!) learn what features they should be emulating in their software? Prior to this book, there was only one published source. Written in 1990, The RenderMan Companion (Upstill, 1990) is still excellent as a first course in using RenderMan, but it has at least two limitations. First, it is only an introductory course. There are a lot of topics of technical interest (and technical necessity) that are simply not covered, such as shader antialiasing techniques. Second, it is 10 years old. The fact that it doesn't discuss RIB is only the first of its anachronisms. Although the things that it does say are generally still true, some of the most interesting features of the modern RenderMan renderers are simply not there.

In those 10 years, the industry has changed as well. We've seen the rise of CGI from a curiosity used on a few unpopular movies to the dominant paradigm for generating special effects. The CGI community has three hit all-CG movies and a bushel of Academy Awards to its credit, and now owns the mind-set of both the viewing public and the film directors who trust us to realize their most outlandish visions.

During this period of explosive growth, we've all learned a tremendous amount about how to create CGI, how to use CGI, how to run studios, and how to write resumes. The tricks we thought were so clever in 1992 are high school stuff nowadays. The beast needs new food, and that's really why we have written this book. We have amassed a large amount of material from several authors who will present to you some of what they know about making beautiful images. We've attempted to codify a large nebulous body of knowledge that has come out of our experiences creating CGI for motion pictures at a variety of motion picture and special effects studios. An uncountable number of individuals have added to this lore: immediate colleagues of the authors, our devoted customers, and the computer graphics industry at large. We thank you all for your fabulous ideas.

We hope the techniques and tricks we present in this book, and their results, will inspire you to make even more beautiful images, and realize even more outlandish visions, than any we've yet seen. After all, we're in the audience, too, and we love this stuff! Dazzle us!

Review of

Mathematics and

Computer Graphics

Concepts

Let's face it. Before we get started writing RenderMan models and shaders in earnest, let's acknowledge that we just don't have quite as much background in math, physics, or even long-standing computer graphics concepts as we know we should have. There are plenty of reasons: didn't get to take the right courses in college, the professor was too boring to sit through, got into computer graphics by way of a mechanical engineering degree, or, hey, I'm an artist, not a programmer. It doesn't matter. Read this chapter in the privacy of your own home, while no one is looking, and no one ever need know that you skipped that lecture on matrix multiplication.

This chapter is a summary and review of a few important topics with which advanced RenderMan users should be fluent. It is in no way a complete treatise on these subjects. Readers who are interested in studying these topics in more depth are referred to any of the very excellent math, physics, and computer graphics textbooks that were written specifically to teach them. A few such texts are mentioned at the end of this chapter.

2 Review of Mathematics and Computer Graphics Concepts

2.1 Trigonometry and Vector Algebra

Trigonometry is the mathematics of angles. Vector algebra is the manipulation of variables that have more than one number in them. Trigonometry and vector algebra are widely used to describe and implement computer graphics algorithms that manipulate geometric data because they are easy ways to put geometric concepts into the form of equations. These topics are, of course, very large fields of mathematics, but fortunately for RenderMan users, much of the day-to-day utility of these subjects can be summarized in a few simple concepts.

2.1.1Trigonometry

Trigonometry is a vast and time-honored field, from the genesis of mathematics in Egypt to the dreaded high school math course where we had to do those horrible proofs. Fortunately, we use very few of those equations every day, even as full-time RenderMan shader writers.

As is common in ancient fields of study, angles can be measured in a variety of different units, and in RenderMan two of these appear: degrees and radians. Degrees are probably very familiar to everyone. There are 360 degrees in a circle, a right angle is 90 degrees. Degrees are used whenever angles are needed in the geometric scene description part of RenderMan as in RenderMan Interface Bytestream (RIB) commands, for example. Radians, on the other hand, are familiar to mathematicians and programmers. There are 2n radians in a circle, a right angle is z radians. Radians are used whenever angles are needed in the Shading Language. Of course, it is simple to convert between them because we know that 360 degrees equals radians.

The three most important trigonometric functions are sine, cosine, and tangent. These functions are defined by the relationships among the lengths of the sides of a right triangle. A right triangle, of course, is one that has a right angle in it. The left side of Figure 2.1 shows a standard right triangle. The marked angle 8 is made by two of the sides of the triangle, denoted as the adjacent side (which goes towards the right angle) and the hypotenuse, which is the longest side of the right triangle. The famous Pythagorean theorem (sing it with me now, "a^2 + b^2 = c^2") tells us that the square of the length of the hypotenuse (c) is equal to the sum of the squares of the other two sides. We'll call the third side the opposite side, for relatively obvious reasons. Because the opposite and adjacent sides have a right angle between them, they are perpendicular to each other.

The sine function is defined as the ratio of the length of the opposite side to the length of the hypotenuse. The cosine function is the ratio of the length of the adjacent side to the length of the hypotenuse. The tangent function is the ratio of