- Shopping Bag ( 0 items )
Explore the Power of RenderMan:
*Use the entire range of geometric primitives supported by RenderMan
*Understand how and when to use procedural primitives and level of detail
*Master every nuance of the Shading Language
*Write detailed procedural shaders using texture, displacement, pattern generation, and custom reflection models
*Write shaders for special effects relating to volumes, custom lighting, and non-photorealistic media
*Use antialiasing to ensure that your shaders are free of artifacts
*Minimize the expense of rendering scenes by optimizing input
Other Features from Advanced RenderMan:
Offers expert advice and instruction applicable to any RenderMan-compliant renderer
*Filled with technical illustrations and many full-color representations of effects supported by the RenderMan standard
*Includes a chapter reviewing key math and computer graphics concepts
"...an authoritative, up-to-date resource on the RenderMan Interface Specification...includes tips for avoiding mistakes, an appendix covering key math skills, & many technical illustrations...also offers a companion Web site."
The grid is then passed into the shading system to be shaded. PRMan first evaluates the displacement shader, which may move grid vertices and/or recompute shading normals. Then the surface shader is evaluated. In a typical surface shader, there are calls to diffuse or illuminance somewhere in the code. These routines require the evaluation of all of the light shaders attached to the object. The light shaders run as "coroutines" of the surface shader the first time that they are needed, but their results are cached and reused if they are accessed again (for example, in a subsequent s pe c u 1 a r call). When the surface shader finishes, it has computed the color and opacity of every grid vertex. Finally, the atmosphere shader is evaluated, making adjustments to the vertex color and opacity to simulate fog or other volumetric effects. The end result of all of these evaluations is that the grid now has final color and opacity assigned to each vertex, and the vertices themselves might be in different places than when originally diced. The other attributes of the original primitive are now mostly superfluous.
The details of the method that the shading system uses to assign color and opacity to each grid vertex are of very little consequence to the REYES pipeline itself but, of course, are of central importance to the users of PRMan. However, readers who are not very familiar with the material in Chapters 7 and 11 will probably want to review those chapters before spending too much time worrying about these details.
PRMan's shading system is an interpreter for the RenderMan Shading Language, which reads thebyte-codes in the slo Me previously created by the Shading Language compiler (Hanrahan and Lawson, 1990). Notice that the data structure that the interpreter operates on, a grid, is a bunch of large rectangular arrays of floating-point numbers. For this reason, it may not be surprising that the interpreter actually executes as a virtual SIMI) (single instruction, multiple data) vector math unit. Such vector pipelines were typical in 1980s-vintage supercomputers.
The run-time interpreter reads shader instructions one at a time and executes the operator on all grid vertices. It is important to contrast this scheme with the alternative, which would run the entire shader on the first grid vertex, then run it on the second grid vertex, and so on. The advantages of the breadth-first solution is efficiency. We are able to make near-optimal use of the pipelined floating-point units that appear in modern processors, and we have excellent cache performance due to strong locality of reference. In addition, for un i form variables, the grid has exactly one data value, not nvertices values. As a result, the interpreter is able to compute operations on uniform data exactly once on each grid, saving significantly over the redundant calculations that would be necessary in a depth-first implementation.
However, life is never all gravy. When a conditional or loop instruction is reached, the results may require that not all points on the grid enter the protected block. Because of this, the SIMI) controller has run flags, which identify which grid vertices are "active" and which are "inactive" for the current instruction. For any instruction where the run-flag vector has at least one bit on, the instruction is executed, but only on those grid vertices that require it. Other operators such as el se, break, and continue manipulate the run flags to ensure that the SIMI) execution accurately simulates the depth-first execution.
Another advantage of the SIMI) execution model is that neighborhood information is available for most grid vertices (except those on the grid edges), which means that differentials can be computed. These differentials, the difference between values at adjacent grid vertices, substitute for derivatives in all of the Shading Language operators that require derivative information. Those operators, known generically as area operators, include Du, calculatenormal, texture, and their related functions. Notice that grid vertices on edges (actually on two edges, not all four) have no neighbors, so their differential information is estimated. PRMan version 3.8 and lower estimated this poorly, which led to bad grid artifacts in secondderivative calculations. PRMan version 3.9 has a better differential estimator that makes many of these artifacts disappear, but it is still possible to confuse it at inflection points.
The number and size of texture maps that are typically used in photorealistic scenes are so large that it is impractical to keep more than a small portion of them in memory at one time. For example, a typical frame in a full-screen CGI animation might access texture maps approaching 10 Gb in total size. Fortunately, because this data is not all needed at the highest possible resolution in the same frame, mip-maps can be used to limit this to 200 Mb of texture data actually read. However, even this is more memory than can or needs to be dedicated to such transient data. PRMan has a very sophisticated texture caching system that cycles texture data in as necessary, and keeps the total in-core memory devoted to texture to under 10 Mb in all but extreme cases. The proprietary texture file format is organized into 2D tiles of texture data that are strategically stored for fast access by the texture cache, which optimizes both cache hit rates and disk 1/0 performance.
Shadows are implemented using shadow maps that are sampled with percentage closer filtering (Reeves, Salesin, and Cook 1987). In this scheme, grid vertices are projected into the view of the shadow-casting light source, using shadow camera viewing information stored in the map. They are determined to be in shadow if they are farther away than the value in the shadow map at the appropriate pixel. In order to antialias this depth comparison, given that averaging depths is a nonsensical operation (because it implies that there is geometry in some halfway place where it doesn't actually exist), several depths from the shadow map in neighboring pixels are stochastically sampled, and the shadowing result is the percentage of the tests that succeeded.
After shading, the shaded grid is sent to the hidden-surface evaluation routine. First, the grid is busted into individual micropolygons. Each micropolygon then goes through a miniature version of the main primitive loop. It is bounded, checked for being on-screen, and backface culled if appropriate. Next, the bound determines in which pixels this micropolygon might appear. In each such pixel, a stochastic sampling algorithm tests the rnicropolygon to see if it covers any of the several predetermined point-sample locations of that pixel. For any samples that are covered, the color and opacity of the micropolygon, as well as its depth, are recorded as a visible point. Depending on the shading interpolation method chosen for that primitive, the visible-point color may be a Gouraud interpolation of the four micropolygon corner colors, or it may simply be a copy of one of the corners. Each sample location keeps a list of visible points, sorted by depth. Of course, keeping more than just the frontmost element of the list is only necessary if there is transparency involved.
Once all the primitives that cover a pixel have been processed, the visible-point lists for each sample can be composited together and the resulting final sample colors and opacities blended together using the reconstruction filter to generate final pixel colors. Because good reconstruction kernels span multiple pixels, the final color of each pixel depends on the samples not merely in that pixel, but in neighboring pixels as well. The pixels are sent to the display system to be put into a file or onto a frame buffer.
Motion Blur and Depth of Field
Interestingly, very few changes need to be made to the basic REYES rendering pipeline to support several of the most interesting and unique features of PRMan. One of the most often used advanced features is motion blur...
2. Review of Math and CG Concepts
3. Describing Models
4. Geometric Primitives
5. Handling Complexity
6. How PhotoRealistic RenderMan Works
7. Introduction to Shading Language
8. Texture Mapping and Displacement
9. Illumination Models and Lights
10. Pattern Generation
11. Shader Antialiasing
12. A Gallery of Procedural Shaders
Tricks of the Trade
13. Storytelling Through Lighting
14. CG Lighting Controls
15. Volumetric Shaders for Visual Effects
16. Non-Photorealistic Rendering
17. Ray Tracing in PRMan