Appendix I - RenderMan Interface Revisions

In this section the differences between RenderMan Interface Versions are revealed.

Version 3.3  

Version 3.2

Version 3.1  

Differences Between RI, Versions 3.3 and 3.2  (DRAFT)

Several new API calls have been added to the RenderMan Inteface:

• Conditional RI Evaluation: RiIfBegin, RiElseIf, RiElse, RiIfEnd
• Inline Archives: RiArchiveBegin, RiArchiveEnd
• Scoped Coordinate Systems: RiScopedCoordinateSystem
• Display channel specification: RiDisplayChannel

A new class specifier, facevarying, has been added to describe per-face, linearly interpolated, primitive variables for mesh-like primitives (RiSubdivisionMesh and the RiPointsPolygons variants).

RiBlobby now accepts a threshold control.

The RIB format now supports arbitrary string handles for objects, lights and inline archives.

Arrays are now allowed to be of varying length in certain contexts.

Many new built-in functions, or new variants of existing functions, have been added to the Shading Language, including:

• The gather statement has been added to explicitly support point sampling processes.  The trace call now can now be described in terms of gather.
• The attribute and option functions support access to arbitrary user attributes.
• The textureinfo function now supports the "exists" query.
• New functions:  ambience, transmission, rayinfo, caustic, photonmap, irradiancecache, indirectdiffuse.
  

Differences Between RI, Versions 3.2 and 3.1

Several new API calls have been added to the RenderMan Interface:

• New geometric primitives: RiSubdivisionMesh, RiPoints, RiCurves, RiBlobby
• New built-in procedural routines suitable to use as RiProcedural primitives: RiProcDelayedReadArchive, RiProcRunProgram, RiProcDynamicLoad.
• Reading an existing RIB archive into the renderer at an arbitrary point in the command stream: RiReadArchive.
• New routines affecting the graphics state:  RiCoordSysTransform, RiClippingPlane
• New context management routines: RiContext, RiGetContext

There is no longer an approved K&R C binding of the RenderMan Interface. Instead, only an ANSI C binding is described. All interfaces and examples are now shown in ANSI C in this document.

The following data types have been added to the RenderMan Interface  vector, normal, matrix, hpoint and to ri.h as RtVector, RtNormal, RtHpoint.  The ri.h header file also now defines an RtInt to be an int, not a long.

The storage classes vertex and constant have been added to the RenderMan Interface. A vertex primitive variable must supply the same number of data elements as are supplied for the position, "P", and interpolation
is performed in the same manner as position. A constant primitive variable supplies a single data value for an entire geometric primitive (even an aggregate primitive, like a PointsPolygons). Descriptions of all the geometric primitives have been updated to explain the expected number of data elements for each storage class.

"NDC" space is now a standard space known to an implementation.

Clarified that output depth values are camera space z values, not screen space values.

Clarified that the type parameter of RiDisplay is not limited to be "file" or  "framebuffer", but may be any format or device type name supported by a particular implementation. The "file" and  "framebuffer"  names select the implementation's default file format or framebuffer device.

The RenderMan Interface 3.1 Specification was silent on the number of uniform and varying values supplied for primitive variables on RiNuPatch primitives. The number of varying and uniform variables on an RiNuPatch has now officially been deemed to be computed as if the RiNuPatch is a non-periodic uniform B-spline mesh, rather than a single B-spline patch. Details are given in the RiNuPatch specification.

The 3.1 spec implied that Shading Language variable initialization expressions could only be uniform. That restriction is lifted.

The Shading Language variables du and dv are potentially varying, and are not restricted to be uniform as the 3.1 specification suggests.  A number of new optional arguments to the Shading Language texturing
functions have been added: "blur", "sblur", "tblur", "filter", "fill".

Many new built-in functions, or new variants of existing functions, have been added to the Shading Language, including: inversesqrt, random, transform, vtransform, ntransform, determinant, concat, format, match,
translate, rotate, scale, ctransform, ptlined, filterstep, noise, cellnoise, pnoise, specularbrdf, attribute, option, textureinfo, rendererinfo, min, max, clamp, mix, spline, atmosphere, displacement, lightsource, surface,
Dtime.

The illuminance statement has been expanded to accept category specifiers.

Shading Language has added new variables: dtime and dPdtime.

Rather than strictly requiring user-defined and nonstandard data to be typed using RiDeclare, such tokens can have their types specified "in-line'' by pre-pending the type declaration to the token name.

Renderers may output images composed of arbitrary data computed by shaders, in addition to "rgb'' and so on. Such extra data may also be sent to different output files.

We have clarified that interior and exterior volume shaders are not specific to CSG solids, but rather are shaders that alter the colors of rays spawned by trace() calls in the shaders of the primitive.

RiArchiveRecord now takes verbatim as the record type.

We have clarified that in imager shaders, P is the raster space position of the pixel center, and not the point on any piece of scene geometry.

We have changed the wording of the section that once described the required versus optional capabilities of RenderMan-compliant renderers. A few features previously described as optional, such as programmable shading, texture mapping, and trim curves, have been moved unambiguously to the list of requirements. There is still a list of "advanced features'' that are no longer referred to as "optional",  but it is understood that algorithmic limitations may prevent some implementations from fully supporting those features.

Object Instances are a bit more flexible in 3.2 than they were in 3.1. In particular, relative transformations and Motion blocks are allowed within Object definitions.

Some changes have been made to the required standard shaders: they have been updated to make use of the new data types, the bumpy shader now does displacement instead of using the deprecated bump function, and there is now a standard background imager shader.

A few features previously described are now deprecated due to either having been ambiguously articulated, useless, unimplementable, or having been replaced by more recent and obviously superior features.
These are therefore removed from the RenderMan Interface:

• Deformations and transformation shaders have been eliminated. We now recognize that this functionality is not only ambiguous, but should be considered a modeling feature, not a rendering feature.
• Bump maps (including the RiMakeBump and the Shading Language bump function) have been removed. This functionality is completely subsumed by displacement mapping.
• Support for "Painter's algorithm'' hidden surface removal is no longer required.

Differences Between RI, Versions 3.1 and 3.0

Version 3.1 corrects various typographical and syntactic errors, and a small number of semantic errors present in version 3.0; however, there are no fundamental changes to the structure, concepts or compliance requirements. In addition, version 3.1 introduces a second binding for the RenderMan Interface: the RenderMan Interface Bytestream Protocol (RIB). RIB provides both an archive file format and a network transport protocol for a sequence of RenderMan Interface library calls.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of Pixar. The information in this publication is furnished for informational use only, is subject to change without notice and should not be construed as a commitment by Pixar. Pixar assumes no responsibility or liability for any errors or inaccuracies that may appear in this publication.