What's a Shader? |
|
|
|
The BasicsIn context of the RenderMan Artist Tools, there are "shaders" and then there are "appearances." The two are similar, but they have important distinctions. Knowing what the differences between a shader and appearance are will help ease the management of resources when working with the RenderMan Artist Tools. So, an appearance is the general term we use to describe an individual instance of a procedural entity. A shader is the principal procedural entity and an appearance is a description of how to invoke the procedure. Basically, a shader is a program (written in the RenderMan shading language) that lives on disk as a resource, and an appearance is its interactive front, "appearing" in a palette and referring to one of these shader programs, its master. A shader can have an infinite variety of appearances. Gaving an effective strategy for creating, manipulating, and managing appearances and their shader masters is crucial, especially for large productions. To fully describe an appearance to RenderMan, a number of RIB statements might be required. Typically a shader instance might be described in a RIB file with a few statements that set up the Shader Space, followed by statements describing common material attributes, like color, followed by the RIB shader invocation, which is comprised of the shader type followed by a master reference and a list of parameters coupled with their values. Using Slim you'll notice that there are many appearance types and that the type of an appearance has a large bearing on how you can use it. Above are icons for the most common types of appearances you'll encounter when using Slim. Only four of these types represent RenderMan entities directly and these are discussed in the section on Shaders and Instances below. Most of the remaining appearance types are used as building blocks to develop custom RenderMan shaders. We refer to these building blocks as functions and we describe the principal function types below. Using the Appearance Editor, functions can be connected to other functions' parameters of the same type and this forms a sort of network of connected functions. Before rendering, Slim converts such networks into one of the four RenderMan shader types and then constructs a RIB representation of the appearance with appropriate RenderMan Attributes, where applicable. A few appearance types defy categorization and so we use that characteristic to categorize them. The Special Appearance Types described below do not have a one-to-one correspondence with a RenderMan shader or function. Finally, appearances types that have a RIB representation are
said to be attachable. That is, they can be attached to objects
in a scene via the Slim client. All shader instances, a few function
types, and the special appearance types are attachable. The remaining
function types are not attachable and can contribute to a rendering only
through their effects on the networks of which they're members.
|
|
Shaders: Masters and InstancesSlim supports all four common RenderMan shader types. Any shader that has been compiled into Pixar's .slo file format can be imported into Slim. The .slo file is said to be the appearance master while the imported representation of the shader is called an instance. Once a shader has been converted to .slo format its interface becomes frozen: the number, names, and types of the shader parameters become fixed. However, because the parameter values can be changed, shaders are much more powerful and flexible than texture maps. Shader developers frequently modify and recompile shaders during the development process and Slim provides a reload feature in which a shader instance is synchronized with its master. Because parameters can be renamed, retyped or entirely removed, reloading can result in dramatic changes to your shader instances.
|
|
Functions: Slim Shading NetworksFunctions are the building blocks that Slim assembles into "shading networks" which can then be flattened into RenderMan shaders. When any shader is built interactively, functions are assembled together to create a shading network. There are many types of functions serving many different purposes (or functions!). A fine line exists between a Slim function and a RenderMan shader. Any time you render a function, it must be converted to a RenderMan shader and compiled into a .slo file. This is done on the fly each time a fundamental change is made to your function network. An appearance is said to undergo a fundamental change when you perform one of:
Slim supports functions whose types match the four common RenderMan shader types. The distinction between a surface function and a surface shader is purely semantic. The parameters of a shader are frozen in type and number and, most importantantly, can't be connected to other Slim functions. Sometimes the very inflexibility of a shader is desireable and Slim provides the freeze command to convert a function network into an individual shader instance in your palette. Functions are instances of templates. Templates are usually loaded when Slim is started and carry with them the RenderMan Shading Language (RSL) source code needed by Slim to generate fully functional RenderMan shaders. When Template developers modify a template, Slim's handy reload feature can be used to synchronize template instances with their templates.
|
|
Special AppearanceTypes Special appearance types are not representable as RenderMan shaders.
|
|
Here's a portion of the appearance editor with the attributes associated with a shadow map pass. These attributes control various details about how a map is generated: Frequency - you can choose to generate a map: Never, Every Frame or Once Per Job. Camera Name - the name of the camera to compute the map from. When you specify $OBJNAME, Slim requests a map for every object the Map Generator is attached to. Near - the near clipping plane. When set to 0 we use global defaults. Far - the far clipping plane. When set to 0 we use global defaults. Map Resolution - the resolution of your map, measure in pixels. Maps are always square, but might compensate for the contents via the screen window. Objects in Map - the objects that participate in the map calculations. When empty, all object participate. You can also enter the name of a Maya set here. Laziness - controls when to recalculate a map. Options are: Off, On and Use Global, When Off a new map is calculated each time it's needed. When set to On, MTOR only calculates the map if it's not already present. This setting is useful when you're in a tight interactive loop. When set to Use Global, we simply use the Global setting specified in the Render Globals dialog. Depth Filter - chooses the depth filter for shadowmap generation. Options are: min, max, average and midpt. For more information about using computed maps see: Computed Maps- Generating Maps with Slim. |
Pixar Animation Studios
|