 |
| Depthfilter Minimum |
 |
| Depthfilter Midpoint |
Pixar
September, 1998
These release notes describe significant changes and enhancements to the RenderMan Toolkit for the 3.8 release (and the 3.8C bug fix release) over the 3.7 release. In successive sections, we cover
PRMan now includes support for Catmull-Clark subdivision surfaces. Ordinary cubic B-spline surfaces are rectangular grids of tensor-product patches. Subdivision surfaces generalize these to control grids with arbitrary connectivity, so that when you want a five-sided patch at a shoulder joint you can get it, and when you need more resolution near a character's eyes and mouth you can have it without being required to increase the resolution all across the rows and columns of the control mesh. PRMan's subdivision surfaces are extended to support creases, either infinitely sharp (C0 but not C1) or rounded in a controllable way.
The RI/RIB interface for subdivision surfaces looks a lot like RiPointsPolygon, with additional parameters to permit the specification of semisharp creases, integer datatypes attached to vertices and edges, and other enhancements.
RiSubdivisionMesh(RtToken scheme, RtInt nfaces, RtInt nvertices[], RtInt vertices[], RtInt ntags, RtToken tags[], RtInt nargs[], RtInt intargs[], RtFloat floatargs[], parameterlist)
RiSubdivisionMesh defines a subdivision mesh or surface obeying the subdivision scheme specified by scheme. The token scheme is currently limited to "catmull-clark", specifying the Catmull-Clark subdivision method. The subdivision mesh is made up of nfaces faces. The array nvertices, of length nfaces, contains the number of vertices in each face. The array vertices contains, for each face vertex, an index into the vertex primitive variable arrays. The array vertices has a length equal to the sum of all the values in the array nvertices. All the arrays are 0-based.
A component is either a face, a vertex, or a chain of edges. Components of the subdivision mesh may be tagged to have various user-defined properties. The token array tags, of length ntags, identifies these tags. Each tag has zero or more integer arguments, and zero or more floating-point arguments. The number of arguments provided with each tag is specified by the array nargs, which has a length of ntags times two. For each tag, nargs contains an integer specifying the number of integer operands found in the array intargs, followed by an integer specifying the number of floating-point operands found in the array floatargs. Thus, the length of intargs is equal to the sum of all the even-numbered elements of the array nargs. The length of floatargs is equal to the sum of all the odd-numbered elements of the array nargs.
Several tags are currently defined. The "crease" tag specifies that a certain chain of edges should be a crease. This tag has n integer arguments specifying a chain of vertices that make up the crease, and one floating-point argument giving the crease's sharpness. A crease with sharpness s is subdivided using the sharp subdivision mask for the first s subdivision steps. If s is RI_INFINITY, the edge uses the sharp mask forever and the surface will be C0 but not C1 across the edge. Each sequential pair of vertices in a crease must be the endpoints of an edge of the subdivision mesh. A mesh may have any number of independent "crease" tags.
The "corner" tag may be used to mark certain vertices. This tag has n integer arguments containing the vertex numbers of the corners and either one or n floating-point arguments that specify the sharpness of the corners. A corner with sharpness s will remain fixed for the first s subdivision steps. If s is RI_INFINITY, the corner will stay fixed forever; the surface will interpolate the vertex in a C0 but not C1 manner.
The "interpolateboundary" tag specifies that the subdivision mesh should interpolate all boundary faces to their edges. This tag has zero integer arguments and zero floating-point arguments. It has the same effect as specifying that all the boundary edge-chains are sharp creases and that boundary vertices with exactly two incident edges are sharp corners.
The "hole" tag specifies that certain faces are holes. This tag has n integer arguments, one for each face that is a hole, and zero floating-point arguments. Each face is specified by its index in the nvertices array.
parameterlist is a list of token-array pairs where each token is one of the standard geometric primitive variables or a variable that has been defined with RiDeclare. The parameter list must include at least position ("P") information. If a primitive variable is varying, the array contains n elements of the type corresponding to the token. The number n is equal to the maximum value in the array vertices plus one. If the variable is uniform, the array contains nfaces elements of the associated type.
The RIB Binding is
SubdivisionMesh scheme nvertices vertices tags nargs intargs floatargs parameterlistThe number of faces is determined implicitly by the length of the nvertices array. The number of tags is determined implicitly by the length of the tags array, and must match the value as determined from the nargs array.
Previously PRMan only allowed color, opacity and depth information to be written to displays. People who wanted to extract other information from scenes, say to provide inputs for non-photorealistic post-processes, were required to run multiple PRMan passes with different shaders that computed the needed values and assigned them to Ci.
In release 3.8, the display subsystem is completely rewritten to allow any number of values computed in a shader to be written into files or framebuffers, all in a single rendering pass. The new display subsystem has a new display-driver API using dynamic shared object files (DSOs) to implement drivers. Driver-writing for the new API is covered in the rewritten Display Driver Guide.
The Display RIB command has been modified to allow for arbitrary specification of the output variable. See the section on arbitrary output variables below for more details.
Display name type mode
Since display drivers are now loaded dynamically, PRMan looks in the rendermn.ini file to determine where to find them.
Suppose rendermn.ini contains the lines
/displaytype/file tiff
/displaytype/framebuffer ${RMANFB-myfb}
/display/tiff internal
/display/myfb /usr/me/bin/mydspyserver
/display/dsomapping d_%s.so
/display/standarddsopath ${RMANTREE}/etc/
and suppose a RIB file specifies
Display "frame.tif" "file" "rgba"The following sequence of actions takes place:
Initially, the driver name "file" is taken from the Display statement. With that in hand, PRMan searches for /displaytype/file in rendermn.ini and, on finding the value tiff, rewrites the driver name from "file" to "tiff". Similarly, had the Display command specified "framebuffer", PRMan would have looked for /displaytype/framebuffer and rewritten the driver name to be the contents of the environment variable $RMANFB or "myfb" if $RMANFB were not set.
Having looked up the display type, PRMan searches for a driver command by examining the /display/tiff line. The command is internal, which indicates that the driver is in a DSO using the new display driver protocols. Had the display type instead been "myfb", the driver command would have been /usr/me/bin/mydspyserver, and PRMan would have run this command and communicated with it using the old (pre release 3.8) display protocols.
With the knowledge that it needs to use the new display protocols, PRMan now looks for a /display/dso/tiff entry. If one were present, it would give the pathname of the DSO. Since it's missing, PRMan instead substitutes the driver name tiff for the characters %s in the string on the /display/dsomapping line, creating d_tiff.so as the name of the driver DSO. It then searches the paths specified by /display/standarddsopath, and if not found there, /display/dsopath.
The renderer now accepts searchpaths for display drivers, just as it already did for shaders and textures.
The RIB syntax is:
Previous versions of PRMan handled motion-blur by linearly interpolating the position of primitives from shutter open to shutter close. In situations where an object is rotating rapidly, this approximation is often obviously incorrect.
PRMan 3.8 fixes this limitation by permitting a piecewise linear interpolation of positions within a single frame. The RIB file syntax is exactly as described in the RenderMan Specification. Each motion-block specifies a sequence of times, and there is one version of the transformation (or object specification) that corresponds to each time value. The shutter specifies the range of these times will appear in the frame, and the motion is piecewise linearly interpolated between the knots at the given times.
For example:
Shutter [0.0 1.0]
...
MotionBegin [0.0 0.25 0.75 1.0]
Translate 0.0 10.0 0.0
Translate 10.0 0.0 0.0
Translate 0.0 0.0 20.0
Translate 0.0 0.0 0.0
MotionEnd
Sphere 1 -1 1 360
describes a ball that is moving around violently in 3-D.
As with previous versions of motion-blur, transformations and object deformations are both legal inside the motion block. There is an arbitrary limit of no more that 6 unique time values specified throughout in the RIB file as a whole. That is, you can use up to 6 time values in any motion-block, as long as it's always the same 6 times.
The shutter open and close times are not required to match any of the specified time values, and if they do not, the objects and transformations will be correctly clipped to the shutter's range. For example, the shutter in the above example could run from 0.1 to 0.9, and the "right thing" would happen. If the shutter extends outside the range specified in the motion block, two things happen. Transformations are clamped to their endpoints. In the example above, the ball is considered stationary at (0,10,0) prior to time 0.0, and stationary again at (0,0,0) after time 1.0. Geometry, on the other hand, is non-existent outside of the motion-block's time range. Therefore, one may have a geometry appear in the middle of a frame, or similarly vanish intraframe.
Rotations are not divided into segments automatically. Rotations that need more temporal resolution must be specified by the model (or the RIB generation program) as follows:
Shutter [0.0 1.0]
...
MotionBegin [0.0 0.25 0.50 0.75 1.0]
Rotate 0.0 0.0 1.0 0.0
Rotate 10.0 0.0 1.0 0.0
Rotate 20.0 0.0 1.0 0.0
Rotate 30.0 0.0 1.0 0.0
Rotate 40.0 0.0 1.0 0.0
MotionEnd
In the current implementation, shading of each segment of the object's motion is calculated independently, at the time value that represents the beginning of that segment. However, shading parameters can not yet be interpolated through time. Therefore, any shading differences that are due only to position will be visible on the various segments of the motion path (for example, specular highlight location). Note that shadows are evaluated only at shutter open time.
Normally the renderer currently culls one-sided primitives that are backfacing. A primitive is considered backfacing if the primitive's surface normals all point more than 90 degrees away from the viewing vector. In PRMan version 3.7 and earlier, this culling was not guaranteed to occur. Primitives might not be culled even though they were truly backfacing, and no primitive was ever cut cleanly along the terminator. Thus, transparent one-sided objects may have shown inconsistent or ragged-edged results as parts, but not all, of the backfacing sections were culled. Moreover, there was a culling phase prior to shading that could have had the unexpected effect of culling backfacing geometry that a displacement shader would have subsequently moved into a front-facing orientation.
PRMan 3.8 modifies these behaviors. First, backface culling is guaranteed to occur and to be exact; no transparency artifacts as described above will occur.
Second, the threshhold for backface culling of one-sided primitives prior to shading can be adjusted with the new sides:backfacetolerance attribute. The backface culling tolerance angle is a floating-point number, measured in degrees, which specifies the angle that the primitive must exceed, beyond the “silhouette normal”, before it may be culled prior to shading. The default value is 0 degrees. For example:
Attribute "sides" "backfacetolerance" [20]will cause the renderer to not cull backfacing objects until their surface normals point more than 110 degrees away from the viewing vector. Note that this does not affect the fact that by the end of the rendering pipeline, backface culling is exact and occurs at 90 degrees.
In older versions of PRMan, program and DSO names had to be absolute pathnames, and there was no way to specify a different executable depending on which machine-architecture the RIB file was being rendered on. In PRMan 3.8, the renderer will expand the string $ARCH or %ARCH in any procedural primitive program and DSO pathnames, converting it into a string that identifies the machine architecture.
The default architecture names are:
| sgi_m3 | SGI workstation (compiled with -mips3 -n32) |
| sparc | Sun SPARC |
| alpha | DEC Alpha (running OSF/1) |
| linux | Intel x86 (running RedHat Linux) |
A significant bug that made procedural primitives significantly inefficient if they crossed the eye plane has been fixed. Now procedural primitives are never opened during the RIB parsing phase, and will never be called recursively due to eyesplits.
RiProcRunProgram used to require that its program ran in a loop, reading input “description” strings and emitting the results until the renderer signalled that there was no more input. It is now significantly more robust, and will handle programs that read exactly one input string, process it and immediately exit. Also, RiProcRunProgram will no longer hang or core dump if the specified program does not exist or cannot be executed.
The renderer now accepts searchpaths for RIB archive files, just as it already did for shaders and textures. This searchpath is used to expand RIB archive filenames when used in either RiReadArchive or RiProcedural("DelayedReadArchive", ...).
The RIB syntax is:
The rendermn.ini file has two new values for archive searchpaths, /archivepath and /standardarchivepath, which both default to "." (just the current directory).
The tiff output driver can now handle rgbaz images, by writing the Z data into a separate zfile. If you specify the following RiDisplay command:
End of frame statistics are controlled by the RIB statement:
Option "statistics" "endofframe" [level]The value of level determines how much detail is printed:
The maximum number of times that a primitive may be split into order to resolve camera-plane crossing and ambiguous perspective issues (the "eyesplits" limit), is now an attribute. The existing eyesplits limit option will continue to exist, and will be used for any primitive that does not override that value with the new eyesplits limit attribute.
Option "limits" "eyesplits" [n] Attribute "limits" "eyesplits" [n]
RenderMan objects, delimited by RiObjectBegin and RiObjectEnd, have always been extremely limited in that they could only define a flat, attributeless list of geometric primitives, all of the same type.
In PRMan 3.8, most, but not all, of these restrictions are removed, giving objects significantly more utility:
PRMan 3.8 supports a new syntax for parameter declarations. In the past, parameterlist variables needed to be declared in RiDeclare prior to their use. Now, parameters can also be declared `inline.' The syntax for the declaration is identical to the RiDeclare syntax, but the parameter declaration is not added to the global symbol table. Instead, the declaration takes effect for that one parameterlist value only. For example, the code
Declare "roughness" "uniform float"
Surface "plastic" "roughness" [0.3]
Surface "benighted" "Kd" [0.5] "uniform color roughness" [0.1 0.3 1.0]
Surface "plastic" "roughness" [0.1]
passes a color version of roughness only to the benighted surface.
The displacement-bound attribute is specified by stating a maximal radial displacement distance in a particular coordinate system. In 3.7 and prior releases, the coordinate system is specified by naming a predefined or user-defined coordinate system (as per RiCoordinateSystem).
In version 3.8, the coordinate system may be specified by supplying a transformation matrix. The parameterlist name for this version of the call is "transform", and the value is a single transformation matrix. The semantics of this transformation matrix is parallel to passing a transformation matrix to a shader and transforming a point through it. In other words,
Attribute "displacementbound" "sphere" [2] "coordinatesystem" ["world"]is to
dispmag = sphereradius * ntransform("world", Nf);
asAttribute "displacementbound" "sphere" [2] "transform" [...mx...]is to
dispmag = sphereradius * ntransform(mx, Nf);
RenderMan Shading Language has always had a rich library of built-in functions (sometimes called "shadeops"). This built-in function library included math operations (sin, sqrt, etc.), vector and matrix operations, coordinate transformations, etc. It has also always been possible to write user-defined functions in Shading Language itself. Improvements to function syntax and semantics and compiler robustness was specifically addressed by the new Shading Language compiler, nshader. However, defining functions in the SL itself has several limitations.
PRMan 3.8 allows you to write new built-in SL functions in C or C++. Such functions overcome many of the limitations of SL-defined functions. .
PRMan 3.8 introduces support for “light categories”. Previously all light source shaders attached to an object were evaluated simultaneously whenever a shader requested light values by calling diffuse, for example, or in illuminance loops. There was no mechanism for executing a single light source shader at a time. PRMan 3.8 allows lights to be tagged with a set of category identifiers, and illuminance statements to request evaluation of only those shaders that match particular categories. Other light shaders will not be evaluated until their categories are requested.
Light shaders can specify the categories to which they belong by declaring a uniform string parameter named __category (this name has two underscores), whose value is a comma-separated list of categories into which the light shader falls. For example,
lightsource uvglow (
float intensity = 0.5;
output varying color uvcolor = 0;
uniform string __category = "uv,photonic,Tony") {
solar(vector "shader" (0,0,1), 0) {
Cl = intensity;
uv = 1.0;
}
}
The value of this parameter may be a compile-time default,
or may be specified in the RIB file,
but may not be computed by the shader -- the parameter cannot be output.
Other shaders that have illuminance loops may specifically execute, or specifically exclude from execution, lights in any particular category. This is done with an optional string parameter to the illuminance block, which is matched against the categories of each light source. Only light sources that match will be run. If the string value starts with a hyphen, then any matched light sources will be excluded, and all other lights will be run. For example,
surface foo ( ) {
color uv = 0;
illuminance("uv", P) {
lightsource("uvcolor", uv);
}
illuminance("-uv", P) {
Ci += Cl;
}
}
PRMan had another major bug in the matrix constant construction shadeop. For example, lines of the form
M = matrix "shader" 1;
generated the inverse of the matrix that was intended.
That is to say, M was documented to be and was supposed to be
the current-to-shader matrix,
but the operator actually returned the inverse of this.
To fix the problem without removing functionality that old shaders may empirically depend on, a new keyword matrixinv has been introduced to have the functionality of the old, broken matrix, and matrix has been adjusted to return the correct forward matrix. N.B.: This change breaks old shaders that use matrix.
shadow(..., "filter", "gaussian")shadow() calls in the shading language can now specify a gaussian filter for the "percentage-closer" filtering in shadow maps. As with the box filter, increasing the filter width makes shadow edges blurrier, but increases the danger of speckling due to shadow map bias.
texture(..., "filter", "disk")
texture(..., "filter", "radial-bspline")
texture() calls in the shading language can now specify a
disk filter or at radial-bspline filter
in addition to the gaussian and
box filters. The disk filter is optimized for large
blur sizes, and (unlike the other filters) is free of mipmap
artifacts because it uses all mipmap levels in its computations;
it is about twice as expensive as the other filters.
The radial-bspline filter is specifically designed
for optimally filtering displacement textures.
On a related note, the "gaussian" texture filter, which used to be truncated at a fixed width, is now windowed using a Blackman-Harris window, so that it goes to zero at the edge of the window and is C1 continuous.
Previously shadow maps have always contained the minimum depth value calculated from all depth values within the current pixel. The user now has control over the function that computes the output depth value for each pixel. This is controlled by a new Hider option called "depthfilter". You can now select between the minimum, maximum, or average of the pixel depth values to output.
Examples using the jitter hider:
Hider "hidden" "jitter" [0] "depthfilter" "min" Hider "hidden" "jitter" [0] "depthfilter" "max" Hider "hidden" "jitter" [0] "depthfilter" "average"
In addition, there is one special version of the depth filter that works a bit differently. For each sample position, it calculates the depth as the midpoint between the object that is closest to the viewpoint and the second closest object. This requires a bit more time than the other techniques, but generates z values that may require less tweaking and biasing. This method was proposed by Andrew Woo of Alias Research in Graphics Gems III , page 338.
This method is specified by the Hider statement:
Hider "hidden" "jitter" [0] "depthfilter" "midpoint"
As an example, here are two shadow maps, the first generated normally, the second generated using the midpoint algorithm. Notice that the ground plane disappears entirely in the midpoint shadow map. In these pixels, there is only the ground plane visible, so it can't possibly shadow any other objects in the scene. This prevents any kind of bias errors for the ground plane; the shadow map would work properly even if the ground were displaced into a bumpy surface.
|
| Depthfilter Minimum |
|
| Depthfilter Midpoint |
PRMan 3.8 has an enhanced shadow shadeop supporting a new method of generating soft shadows with true penumbral fadeout, simulating shadows of area light sources. The method uses multiple rendered shadow maps to infer visibility information from a light source whose extended geometry is also specified in the shadeop.
The enhanced shadow call is fully backwards-compatible, but supports a new form to allow specification of multiple shadow maps in a single call:
float shadow(string maplist, texture coordinates[, parameterlist])where maplist is a comma-separated list of shadowmap filenames.
In the past, the location of the point light source (as far as shadows were concerned) was implicit in the shadow map matrices. When using multiple maps to simulate an area light source, the user must also specify the size and shape of the intended light source in the shadow shadeop. The following new parameters to shadow support this new soft shadow method:
This new method of generating soft shadows requires multiple shadow maps to infer geometry between the surface being shaded and the light source. For best results, the views should be placed on or near the light source, pointing in the direction of the objects that will cast shadows. All views should fully contain the shadowing objects, although they will contribute slightly different information (due to their differing viewpoints). Specifying more views gives the renderer more information to work with, and thus can improve the quality of the shadows rendered. However, too many views can be unnecessarily expensive, so caution is advised. For most scenes, three to five shadow maps will be sufficient to capture the geometry sufficiently.
The shadow maps that are used for soft shadow information contain additional mip-map information that makes the soft shadow evaluation more efficient. When creating the .shad files, instead of txmake -shadow file.z file.shad you should use txmake -minmaxshadow file.z file.shad which will generate an extended shadow map file. These files are backwards-compatible with the normal shadow call (the new files can be used in the standard calls), but are required when using the soft shadow form.
An example of the soft-shadow form of shadow, using four shadow maps and a triangular light source would be:
In PRMan 3.8, the shading language adds four new shadeops that provide access to global rendering internal state. In each case, the function is prototypically like the shader variable access functions surface, lightsource, etc. Each function takes a string that is the name of a piece of global data, and a variable to contain the result. The functions return non-zero if the data exists and the variable is of the right type to contain the result, in which case the variable will be filled with the data requested. The functions return zero if any error prevents returning the requested data, including unrecognized requests, unobtainable data and variable type mismatches. Note that the request names are case-sensitive, and correspond exactly to the names of data specified in the RIB Binding of RenderMan. The data that is returned is as would be expected from inspection of the appropriate RenderMan Interface call.
attribute returns data that is part to the primitive's RenderMan Interface attribute state, either from individual RI calls that set attributes or from the RiAttribute call.
float attribute(string, variable);string specifies the piece of RenderMan Interface attribute state that will be returned in variable. The pieces of attribute state that can be retrieved are:
Note that displacementbound:sphere does not return the value exactly as specified in the RIB file, but rather returns its length in the coordinate system returned by displacementbound:coordinatesystem (which currently always returns "camera").
option returns data that is part of the image's RenderMan Interface global option state, either from individual RI calls that set options, or from the RiOption call.
float option(string, variable);string specifies the piece of RenderMan Interface option state that will be returned in variable. The pieces of option state that can be retrieved are:
textureinfo returns data that describes the format of a texture file.
float textureinfo(filename, string, variable);string specifies the information about the texture file named filename which will be returned in variable. The pieces of texture information that can be retrived are:
rendererinfo returns information that describes the renderer itself.
float rendererinfo(string, variable);string specifies the piece of renderer information that will be returned in variable. In version 3.8, the only pieces of renderer information that can be retrieved are:
PRMan 3.8 supports smooth differentials and derivatives in Shading Language. RenderMan's derivatives functions (Du(), Dv(), Deriv()) and surface differentials (du, dv) are fundamental to writing shaders that antialias well. In earlier versions of PRMan, surface differentials have not been continuous across the surface, but instead were uniform float values on an individual grid, and that changed discontinuously from one grid to the next. This could result in subtle filtering artifacts, particularly on large objects viewed in perspective. Starting with version 3.8, PRMan has a new way of computing differentials that is free from grid discontinuities, by using smoothly varying estimates of the optimal size of micropolygons, rather than their exact size. This allows higher-quality antialiasing of shaders. Further, the shading language area functions (texture(), Du(), filterstep(), etc.), that implicitly use these differentials when filtering, benefit immediately from smooth differentials, automatically removing many grid artifacts previously ascribed to these functions.
This automatic smooth derivative behavior can be turned off, reverting to the pre-3.8 behavior, on a shader-by-shader basis using the shader compiler's -nosd flag. The complementary flag -sd turns smooth derivatives on and is the default.
In most renderers, the user is limited to displaying a limited set of outputs (usually the color, the opacity and depth). The 3.8 release of PhotoRealistic Renderman, the user may export arbitrary information from shaders and write them out to separate files or framebuffers, all within a single rendering pass.
The RiDisplay call has been modified to allow for arbitrary specification of the output variable. Previously, RiDisplay statements have been
Display "name" "type" "mode"
where mode is some combination of rgb, a, and z. The mode may now be specified as any shader variable name which has been declared with RiDeclare. Additionally, certain external variables are also legal, namely
| Name | Meaning |
|---|---|
| P | the XYZ coordinates of the surface point |
| N | the normal at the surface point |
| Ng | the geometric normal at the surface point |
| dPdu, dPdv | the tangent vectors to the surface |
| s, t, u, v | the texture coordinate |
| du, dv | the stepsize in u and v |
| dPdtime | the motion vector for the point P |
| Cs, Os | default surface color and opacity |
| Ci, Oi | computed surface color and opacity |
The RiDisplay call has also been modified to support multiple simultaneous output files. To indicate that a display should be added to the current list of displays, the first character of its name should be a single ASCII plus sign ('+'). For example, the statements
Display "foo.tif" "tiff" "rgb" Display "+goo.tif" "tiff" "N"
would create two separate output files, the first containing the normal rgb color channels, and the second containing the normals. If an additional Display statement was issued without a leading plus sign, then it resets all the displays and becomes the only active display. The first Display call (the one without a leading plus) must be a previously recognized Display statement: its mode must be a mix of rgb, a, and z. Each additional Display must not contain any of those fields.
If the output mode is not one of the special external variables, the shader must create it as an output variable. For example, the simple shader below:
surface
myplastic( float Ks=.5, Kd=.5, Ka=1, roughness=.1; color specularcolor=1;
output varying color foo = 0; output varying float goo = 0;)
{
normal Nf;
vector V;
float invisible ;
Nf = faceforward( normalize(N), I );
V = -normalize(I);
Oi = Os;
foo = diffuse(Nf) ;
goo = s ;
invisible = t ;
Ci = Os * ( Cs * (Ka*ambient() + Kd*diffuse(Nf)) +
specularcolor * Ks * specular(Nf,V,roughness) );
}
the variables foo and goo may be displayed by in a display since they are defined as output variables by the shader. The variable invisible may not be displayed because it is not defined as an output variable. If a particular variable cannot be found in a shader, the display system merely writes a zero in its place. In the RIB stream, one must be careful to predeclare any shader output variables that are to be used for display prior to the call to RiDisplay.
Some limitations do exist:
More complete documentation, with some application ideas can be found in the application note Using Arbitrary Output Variables in PhotoRealistic Renderman (With Applications)
NURBS and Bezier dicing has been rewritten, fixing many small cracks. In addition, a subtle bug in normal vector computation has been fixed.
RiCurve now splits curves by knot insertion.
The size of RiPoints is now specified with the "width" or "constantwidth" parameter rather than "radius". "width" lets you specify the width on a per-point basis; "constantwidth" gives a single width for all points in the "P" array.
There used to be a limit on the number of arguments to a shader. This has been removed.
The shader compiler understands several new options:
The texture subsystem can now read SGI rgb files. Also, txmake has always rescaled odd-sized images to power-of-two sizes. A significant bug that caused loss of precision in this rescaling has been eliminated.
The netrender command now ignores hosts that report having no slots available. The flag -h #host causes netrender to keep retrying host despite it having no slots. Also, -h host:n abbreviates repeating the -h host specification n times.
A nasty bug in netrender that caused failures when using RiCropWindow has been fixed.
The nrmping command now takes a -p flag that causes it to print the number of available slots.
The sho command now
|
Pixar Animation Studios
|