Advanced_Renderman_Book[torrents.ru]

3 Describing Models and Scenes in RenderMan

70

Figure 3.1 The relationship among parts of the image description.

# Camera options Clipping 0.4 1200

Projection "perspective" "fov" [30] ConcatTransform [1 0 0 0 0 0 1 0 0 1 0 0 0 0 0 1] Translate [-20 -8 10]

Rotate 40 0 .6 1 WorldBegin

# Scene Description

. . . . . .

WorldEnd FrameEnd

3.3.1Image Description

The first requirement of the scene description is to specify the image to be made. Several parameters of the image must be determined before any rendering of any kind can be done. These parameters of the image (some of which are illustrated in Figure 3.1) are specified by eight RI API calls.

3.3 Rendering Options

Display filename fileformat imagetype parameterlist

Display sets the name and file format of the output image. The fileformat could be one of any number of specific file formats that the renderer knows, such as "tiff" or "cineon", or the generic names "fi1e" or "framebuffer", where the renderer uses some default format of the appropriate type. The parameterlist specifies optional parameters that are meaningful to the particular image file format, such as compression parameters.

imagetype specifies the type of data (color, depth, etc.) that is to be put into the file. For example, "rgb" and "rgba" request threeand four-channel color images, respectively. The various types of data that a renderer can emit into a file is very dependent on both the capabilities of the renderer and the flexibility of the file format.

Recent versions of PRMan permit multiple images to be created from a single scene description, using multiple calls to Display. In that case, each output image would generally have a different output type.

Format xresolution yresolution pixelaspectratio

Format specifies the resolution of the image to be generated. The pixelaspectratio parameter defines whether the pixels of the image should be square (as they are for most computer monitors) by specifying 1.0, or some other rectangular shape (such as 0.9 for televisions).

FrameAspectRatio ratio

FrameAspectRati o specifies exactly the aspect ratio of the final rendered frame. This can be important if the image is being generated for some anamorphic format, such as 2.35 for Cinemascope frames.

You might notice that these calls redundantly specify certain image parameters, and that might lead to their being inconsistent. For example, the parameter to the FrameAspectRatio call and the frame aspect ratio implied by the Format call can easily be inconsistent. It was intended that the user specify only the most important one, and a reasonable default value would be guessed for the unspecified ones. If incompatible settings are specifically requested, the renderer compromises as best it can.

Exposure gain gamma

Exposure controls the gamma correction (see Section 2.4.2) of the output image. By default, the renderer writes files with no gamma correction (also known as linear gamma). By specifying a floating point gamma value, a gamma appropriate for a particular display or printing device can be set. The floating point gain parameter simply scales all output values uniformly, a function

72 3 Describing Models and Scenes in RenderMan

that is useful to punch up dark scenes without modifying all of the lights. RenderMan does not have any "automatic gain control."

Quantize imagetype one min max dither

Quantize controls the way that floating point data computed by the renderer is converted into the integer data that is required by most file formats. The parameter one specifies the integer value that corresponds to floatingpoint 1.0. min and max specify the minimum and maximum values that the file format will accept. Generally, these are 0 and one, but some file formats can store values that are out of range, either negative intensities or superwhite values. If all three of these parameters are set to 0.0, quantization is turned off and full floating point values are presented to the display.

dither controls the dithering of floating point values as they are quantized, as described in Section 2.4.2. A random number between 0.0 and dither is added to each floating point number before it is truncated to create integer values. Generally, this is set to either 0.0, to turn dither off, or 0.5, to set dithering to round up or down equally often.

The imagetype parameter specifies which type of data this Quantize call refers to. It is common for different types of data to be quantized differently, such as quantizing "rgba" to 8-bit integers while leaving "z" depth values in floating point.

Pixel Samples nx ny

Most modern renderers do antialiasing via supersampling. The Pixel Samples call controls the level of antialiasing by specifying the number of samples per pixel in the x and y directions. Typical values for Pixel Samples range from 2 by 2 when simple antialiasing is needed, through 8 by 8 or higher when more stochastic sampling is needed to support motion blur or depth of field (Section 3.8).

Pixel Fi1ter filtername xwidth ywidth

High-quality antialiasing requires full control over the reconstruction of the individual pixel samples into the final pixel color. Pixel Fi1ter specifies the type and width of the pixel reconstruction filter that is to be used. Filter width is the diameter of the filter kernel, so a filter with xwidth of 3.0 covers a full pixel to the right and to the left of the center of a pixel. Different filters have different qualities, and it is not always obvious which is the right filter for particular applications. For example, most would agree that "box" 1 1 is a pretty poor filter. Some would argue that the windowed "sinc" 4 4 is a great filter, while others would complain about its "negative lobes." The default

3.3 Rendering Options

filter, "gaussian" 2 2, is a pretty good filter with no negative lobes but is a little blurry for some people's tastes.

CropWindow xmin xmax ymin ymax

CropWindow specifies that only a portion of the image should be rendered. The parameters are floating point numbers that specify a box that is the fractional region of the image that is desired (using "NDC" coordinates). Because the values are floating point, they are resolution independent. For example, you can always request the upper-left quarter of the image by specifying CropWindow 0.5 0.5. The floating point values are specifically rounded by the renderer into pixel values so that if the user renders several images with crop windows that tile the unit square in floating point, then every image pixel will be rendered exactly once. Images tiled together from these separately rendered crop windows are dependably free of stitching artifacts.

3.3.2Camera Description

The second requirement of the scene description is to describe the exact parameters of the camera. These include both the position of the camera and the projection of the camera view onto the image.

The position of the camera in the world is specified, as described above, with standard transformation commands that create the transformation matrix that relates "world" space to "camera" space. In particular, "world" space is specified relative to the camera rather than specifying the camera as a position in "world" space. In other words, the camera is not an object in the scene. This is often confusing to first-time users, but it is consistent with the first paradigm requirement that the camera be fixed before any objects are placed before it.

The parameters of the projection (illustrated in Figure 3.2) are specified with three API calls.

Projection type parameterlist

The fundamental job of the camera is to transform objects in 3D onto the 2D projection (or film) plane. In RenderMan, the default projection plane is at z = 1 in "camera" space. Projection specifies the type of camera projection, which then determines where on the projection plane that objects in the scene will appear. RenderMan renderers all support at least "orthographic" projection, which is sometimes called a planar or flat projection, and the "perspective" projection.

The parameterlist provides additional projection-specific parameters. The most common example is the perspective field of view, specified with the "fov" parameter. "fov" takes the full angle (in degrees) of the perspective

3 Describing Models and Scenes in RenderMan

74

Figure 3.2 The relationship among parts of the camera description.

projection, which defaults to 90 degrees. Specifying a different "fov" is equivalent to moving the projection plane (by the tangent of half the angle), which zooms the image.

ScreenWindow xmin xmax ymin ymax

The projection determines where on the projection plane objects in the scene will appear. ScreenWindow specifies the rectangular region of the projection plane that should appear in the image. There is no requirement that the screen window be centered (although it usually is). If it is not, we get an off-center view, such as the ones seen by view cameras. Similarly, there is no requirement that the shape of the screen window match the shape of the frame aspect ratio (although it usually does). If it does not, there will be some anamorphic squashing of the image as it is scaled to fit into the requested output resolution.

The default value for ScreenWindow, if one is not set, is to fit the narrower dimension of the image resolution into the -1.0 to 1.0 range, and center the wider dimension while respecting the frame aspect ratio.

Notice that zooming a perspective camera can be equivalently done by either lowering the perspective "fov" or by narrowing the ScreenWindow. It is best to choose one, as using both simultaneously is confusing.

Clipping nearplane farplane

Clipping sets the near and far clipping planes. Setting the clipping planes is not required but is friendly to the renderer. Clipping planes are commonly used by renderers to optimize their perspective projections, as the math in

3.3Rendering Options

volved in perspective divides tends to waste floating point precision if the scene is not well bounded in depth. In particular, the default values of Cl i ppi ng (nearly zero through infinity) are very bad and really should be overridden by any modeler that has even rough bounds on the overall depth of scene.

3.3.3Renderer Control

In addition to the image and camera parameters, the RenderMan API provides the opportunity for the user to set various other options that control the way the renderer is to create the image. Some of these options control details of advanced rendering features and are described with them in following sections. Other parameters are very renderer specific and are passed into the renderer through the generic extension backdoors like option.

Hider type parameterlist

The Hider call controls the way that the hidden-surface elimination calculation is done. The value type can take the predefined names "hidden", for a normal depth-based hidden-surface algorithm, or "paint", for the rarely used painter's algorithm (the last primitive is on top). Additionally, the renderer might define other names for renderer-specific algorithms. The parameterlist provides the method for giving the renderer any renderer-specific parameters to control the chosen hidden-surface algorithm.

Option type parameterlist

Option provides the entry point for renderer-specific data that is global to the scene or image-generation process and therefore falls into the category of options. For example, both PRMan and BMRT have options that control memory usage, arbitrary limits on various calculations that are theoretically unbounded, rendering mode settings, and so on. These options are generally very algorithm specific, and as a result renderers tend to have non-overlapping sets. Renderers ignore options they do not understand, so it is possible to write RIB files that contain parameters appropriate for multiple renderers.

RiSynchronize("abort")

This special function is available only in the C binding of the RI API. Ri Synchronize("abort") causes the current rendering to be stopped immediately. Whatever pixels have already been generated, if any, are flushed, and the interface returns to the point in the hierarchical state immediately outside the world block. If called prior to Ri WorldEnd(), it pops the attribute stack to the appropriate level. If called while rendering, that is, during the execution of the RiWorldEndO call (for example, in an interrupt handler or in an application subroutine that was supplied to

RiProceduralQ or RiErrorHandlerQ), it immediately exits Ri WorldEnd().

3.4Primitive Attributes

Opacity color

Opaci ty sets the default opacity of geometric primitives. RenderMan does not consider opacity to be a single value, but rather a color filter, so requires a value for each of the three color channels. Therefore, the parameter color is an array of three floating point numbers. Opacity must fall between 0.0 (totally transparent) and 1.0 (completely opaque) for the renderer to work correctly.

These color and opacity values are the ones that will appear in the Shading Language as Cs and Os, unless they are overridden by primitive variable data as defined in Section 4.1.

Matte flag

RenderMan can create images with 3D holdout mattes (see Section 2.4.6 for a discussion of compositing with mattes). Matte objects do not appear in the final rendered frame, and they also remove all objects behind them from the frame as well. As a result, they leave a "hole" in the alpha channel of the final frame, which will undoubtedly be filled later by compositing in some other image. This technique is used when another image must be composited into the middle of a rendered image. Matte objects are used to create an image hole at the appropriate depth, so that objects in front of the matte are rendered normally (and therefore obscure portions of the other image normally), but objects behind the matte are missing to leave room for the image.

The parameter flag is a Boolean value: 1 means the geometric primitive is a matte object; 0 means the primitive is not a matte object. The color and opacity of matte objects do not matter, as they will not be visible nor have any other visible effect on the image.

3.4.2Shaders

The most important attributes of a geometric primitive are the Shading Language shaders that are attached to it. Other references on RenderMan imply that renderers might not have a Shading Language and describe the "default" shaders that every RenderMan renderer must have. Let's get real. Over the last decade we have learned that the Shading Language is one of the most important features that RenderMan has to offer, and it is really not optional. Every existing RenderMan renderer has a Shading Language, and it is certain that future ones will as well, so we'll drop the pretense and just assume that shaders are being used.

Because shaders completely control the calculation of the color of the objects in the scene, various attributes that are familiar and common in other graphics APIs (such as the diffuse coefficient or specular color) do not appear in RenderMan. They are really just parameters of some predefined shading model. Instead, each shader has parameters that are necessary to its shading model, and rather than store them independently in the graphics state, they are simply given in the parameter list of the shader call.

3 Describing Models and Scenes in RenderMan

78

Most shaders have many parameters. In particular, in shaders that are written somewhat generically, there may be many parameters to control subtle variations of that shader. It is quite often the case that many of these parameters may be superfluous to a particular instance of the shader on a particular object. For this reason, every parameter has a default value, and only those parameters that are different from the default need be listed in the parameter list of a particular call. Therefore, the parameter list of each shader call may have different numbers of arguments, perhaps even none. Shader parameters are given in the call's parameter list as a name-value pair of arguments: the parameter name as a string and the parameter value as an array of data of the appropriate type.

There are three key attributes of geometric primitives that are specified as shaders: surface, displacement, and atmosphere. The surface shader is the main shader on any geometric primitive. It is responsible for computing the color and opacity of the primitive. As will be described in detail in later chapters, the surface shader uses the geometric information of the primitive, the parameters of the shader, and light emitted from light source shaders to compute this color (Ci ) and opacity (Oi ).

Surface shadername parameterlist

Surface specifies that the surface shader named shadername should be used to compute the color and opacity of the geometric primitive.

Displacement mapping is a perturbation of the surface, often used to provide pits, dents, embossing, or other small-scale surface position changes that are too small to worry about in the geometric model itself. Displacement mapping literally moves the surface and changes where it will appear on-screen. PRMan can do this in both surface and displacement shaders. BMRT, on the other hand, can only do true displacement mapping in displacement shaders, with attempts to displace in surface shaders resulting in bump mapping. Bump mapping is a visual trick that modifies the surface normal to make it appear as though the surface has smallscale shape distortions without actually moving the surface itself. Of course, a displacement shader could simply compute a bump map without displacement if that is desired.

The displacement shader on a geometric primitive is run prior to the surface shader on that primitive. The function of the displacement shader is to modify the Shading Language global variables "P" and "N" prior to the surface shader being run, so that it operates on the new data.

Displacement shadername parameterlist

Displacement specifies that the displacement shader named shadername should be used to compute surface perturbations on the geometric primitive.

3.5 Other Shading Attributes

When doing true displacements, in either surface or displacement shaders, the renderer needs to know the maximum possible distance that any point might be displaced in order to correctly bound the primitive. See Section 8.2.4 for a complete discussion of specifying the displacement bounds of primitives that have displacement.

RenderMan also provides a shader type whose job is to modify the apparent color of primitives in the scene to simulate atmospheric effects such as fog or distancerelated hue shifts. This shader is known as the atmosphere shader, and it runs after the surface shader has finished. The atmosphere modifies Ci and Oi to account for the visual changes caused by the volumetric effects of the atmosphere between the primitive and the camera.

Atmosphere shadername parameterlist

Atmosphere specifies that the volume shader named shadername should be used to compute the atmospheric contributions to the color of the geometric primitive.

As we will see in Chapter 7, the Shading Language syntax has the flexibility to accept shader parameters that are uniform (the same on all parts of the primitive) and that are varyi ng (different on different parts of the surface). Parameters passed to shader calls require exactly one value, regardless of parameter storage class. Section 4.1 will discuss how variables attached to geometric primitives can also be used to provide different amounts of data to uniform and varying shade

parameters. Notice that such primitive variables always override any parameters which appear in these shader calls.

When "point", "vector", "normal", or "matrix" data (any of the geometric data types) are supplied as a parameter of a shader call, the data is assumed to be expressed in the current coordinate system-that is, in "shader" coordinates. However, as we will see in Section 7.2.3, shader calculations do not happen in "shader" space. Therefore, there is an implied coordinate transformation that brings this "shader" space data into the Shading Language's "current" space before the shader starts execution. If raw, untransformed coordinate values are desired, the easiest way to provide them is through an array of three floats.

3.5Other Shading Attributes

We have just seen how to specify which Shading Language programs should be attached to a geometric primitive to calculate its color. Those shaders are run at many points on the surface of the primitive, depending on where the renderer need to know that information. There are two attributes that determine how often this calculation is made.