Introduction

Features and Capabilities  

The RenderMan Interface is a standard interface between modeling programs and rendering programs capable of producing photorealistic quality images. A rendering program implementing the RenderMan Interface differs from an implementation of earlier graphics standards in that:

• A photorealistic rendering program must simulate a real camera and its many attributes besides just position and direction of view. High quality implies that the simulation does not introduce artifacts from the computational process. Expressed in the terminology of computer graphics, this means that a photorealistic rendering program must be capable of:
  • hidden surface removal so that only visible objects appear in the computed image,
  • spatial filtering so that aliasing artifacts are not present,
  • dithering so that quantization artifacts are not noticeable,
  • temporal filtering so that the opening and closing of the shutter causes moving objects to be blurred,
  • and depth of field so that only objects at the current focal distance are sharply in focus.
• A photorealistic rendering program must also accept curved geometric primitives so that not only can geometry be accurately displayed, but also so that the basic shapes are rich enough to include the diversity of man-made and natural objects. This requires patches, quadrics, and representations of solids, as well as the ability to deal with complicated scenes containing on the order of 10,000 to 1,000,000 geometric primitives.
• A photorealistic rendering program must be capable of simulating the optical properties of different materials and light sources. This includes surface shading models that describe how light interacts with a surface made of a given material, volume shading models that describe how light is scattered as it traverses a region in space, and light source models that describe the color and intensity of light emitted in different directions. Achieving greater realism often requires that the surface properties of an object vary. These properties are often controlled by texture mapping an image onto a surface. Texture maps are used in many different ways: direct image mapping to change the surface's color, transparency mapping, bump mapping for changing its normal vector, displacement mapping for modifying position, environment or reflection mapping for efficiently calculating global illumination, and shadow maps for simulating the presence of shadows.

The RenderMan Interface is designed so that the information needed to specify a photorealistic image can be passed to different rendering programs compactly and efficiently. The interface itself is designed to drive different hardware devices, software implementations and rendering algorithms. Many types of rendering systems are accommodated by this interface, including z-buffer-based, scanline-based, ray tracing, terrain rendering, molecule or sphere rendering and the Reyes rendering architecture. In order to achieve this, the interface does not specify how a picture is rendered, but instead specifies what picture is desired. The interface is designed to be used by both batch-oriented and real-time interactive rendering systems. Real-time rendering is accommodated by ensuring that all the information needed to draw a particular geometric primitive is available when the primitive is defined. Both batch and real-time rendering is accommodated by making limited use of inquiry functions and call-backs.

The RenderMan Interface is meant to be complete, but minimal, in its transfer of scene descriptions from modeling programs to rendering programs. The interface usually provides only a single way to communicate a parameter; it is expected that the modeling front end will provide other convenient variations. An example is color coordinate systems -- the RenderMan Interface supports multiple-component color models because a rendering program intrinsically computes with an n-component color model. However, the RenderMan Interface does not support all color coordinate systems because there are so many and because they must normally be immediately converted to the color representation used by the rendering program. Another example is geometric primitives -- the primitives defined by the RenderMan Interface are considered to be rendering primitives, not modeling primitives. The primitives were chosen either because special graphics algorithms or hardware is available to draw those primitives, or because they allow for a compact representation of a large database. The task of converting higher-level modeling primitives to rendering primitives must be done by the modeling program.

The RenderMan Interface is not designed to be a complete three-dimensional interactive programming environment. Such an environment would include many capabilities not addressed in this interface. These include: 1) screen space or two-dimensional primitives such as annotation text, markers, and 2-D lines and curves, 2) non-surface primitives such as 3-D lines and curves, and 3) user-interface issues such as window systems, input devices, events, selecting, highlighting, and incremental redisplay.

The RenderMan Interface is a collection of procedures to transfer the description of a scene to the rendering program. These procedures are described in Part I. A rendering program takes this input and produces an image. This image can be immediately displayed on a given display device or saved in an image file. The output image may contain color as well as coverage and depth information for post processing. Image files are also used to input texture maps. This document does not specify a "standard format" for image files.

The RenderMan Shading Language is a programming language for extending the predefined functionality of the RenderMan Interface. New materials and light sources can be created using this language. This language is also used to specify deformations, special camera projections, and simple image processing functions. All required shading functionality is also expressed in this language. A shading language is an essential part of a high-quality rendering program. No single material lighting equation can ever hope to model the complexity of all possible material models. The RenderMan Shading Language is described in Part II of this document.

1.1 Features and Capabilities

The RenderMan Interface was designed in a top-down fashion by asking what information is needed to specify a scene in enough detail so that a photorealistic image can be created. Photorealistic image synthesis is quite challenging and many rendering programs cannot implement all of the features provided by the RenderMan Interface. This section describes which features are required and which are considered optional capabilities. The set of required features is extensive in order that application writers and end-users may reasonably expect basic compatibility between, and a high level of performance from, all implementations of the RenderMan Interface. Capabilities are optional only in situations where it is reasonable to expect that some rendering programs are algorithmically incapable of supporting that capability, or where the capability is so advanced that it is reasonable to expect that most rendering implementations will not be able to provide it.

Required features

All rendering programs which implement the RenderMan Interface must implement the interface as specified in this document. Implementations which are provided as a linkable C library must provide entry points for all of the subroutines and functions, accepting the parameters as described in this specification. All of the predefined types, variables and constants (including the entire set of constant RtToken variables for the predefined string arguments to the various RenderMan Interface subroutines) must be provided. The C header file ri.h (see Appendix C, Language Binding Details) describes these data items.

Implementations which are provided as pre-linked standalone applications must accept as input the complete RenderMan Interface Bytestream (RIB). Such implementations may also provide a complete RenderMan Interface library as above, which contains subroutine stubs whose only function is to generate RIB.

All rendering programs which implement the RenderMan Interface must:

• provide the complete hierarchical graphics state, including the attribute and transformation stacks and the active light list.
   
• perform orthographic and perspective viewing transformations.
   
• perform depth-based hidden-surface elimination.
   
• perform pixel filtering and anti-aliasing.
   
• perform gamma correction and dithering before quantization.
   
• produce picture files containing any combination of RGB, A, and Z. The resolutions of these files must be as specified by the user.
  
• provide all of the geometric primitives described in the specification, and provide all of the standard primitive variables applicable to each primitive.
   
• provide the ability to perform shading calculations using user-supplied RenderMan
  Shading Language programs. (See Part II, The RenderMan Shading Language.)
   
• provide the ability to index texture maps, environment maps, and shadow depth
  maps. (See the section on Basic texture maps.)
  
• provide the fifteen standard light source, surface, volume, displacement, and imager
  shaders required by the specification. Any additional shaders, and any deviations
  from the standard shaders presented in this specification, must be documented by
  providing the equivalent shader expressed in the RenderMan Shading Language.

Rendering programs which implement the RenderMan Interface receive all of their data through the interface. There will be no additional subroutines required to control or provide data to the rendering program. Data items which are substantially similar to items already described in this specification will be supplied through the normal mechanisms, and not through any of the implementation-specific extension mechanisms (RiAttribute, RiGeometry or RiOption). Rendering programs will not provide nonstandard alternatives to the existing mechanisms, such as any alternate language for programmable shading.

1.1.2 Advanced Capabilities

Rendering programs may also provide one or more of the following advanced capabilities, though it is recognized that algorithmic limitations of a particular implementation may restrict its ability to provide the entire feature set. If a capability is not provided by an implementation, a specific default is required (as described in the individual sections). A subset of the full functionality of a capability may be provided by a rendering program. For example, a rendering program might implement Motion Blur, but only of simple transformations, or only using a limited range of shutter times. Rendering programs should describe their implementation of the following optional capabilities using the terminology in the following list.

Solid Modeling

The ability to define solid models as collections of surfaces and combine them using the set operations intersection, union and difference. (See the section on Solids and Spatial Set Operations.

 

Level of Detail

The ability to specify several definitions of the same model and have one selected based on the estimated screen size of the model. (See the section on Detail.)
 

Motion Blur

The ability to process moving primitives and anti-alias them in time. (See Section 6, Motion.)
 

Depth of Field

The ability to simulate focusing at different depths. (See the section on Camera.)
 

Programmable Shading

The ability to perform shading calculations using user-supplied RenderMan Shading Language programs. (See Part II, The RenderMan Shading Language.)
 

Special Camera Projections

The ability to perform nonstandard camera projections such as spherical or Omnimax projections. (See the section on Camera.)
 

Deformations

The ability to handle nonlinear transformations such as bends and twists. (See the section on Transformations.)
 

Displacements

The ability to handle displacements. (See the section on Transformations.)
 

Spectral Colors

The ability to calculate colors with an arbitrary number of spectral color samples. (See the section on Additional options.)
 

Texture Mapping

The ability to index a texture map with the surface's texture coordinates. (See the section on Basic texture maps.)
 

Environment Mapping

The ability to model the environmental illumination by indexing a texture map with a direction vector. (See the section on Environment maps.)
 

Bump Mapping

The ability to perturb just surface normals by giving a displacement map. (See the section on Bump maps.)
 

Shadow Depth Mapping

The ability to index a shadow map with a position. (See the section on Shadow depth maps.)
 

Volume Shading

The ability to attach and evaluate volumetric shading procedures. (See the section on Volume shading.)
 

Ray Tracing

The ability to evaluate global illumination models using ray tracing. (See the section on Shading and Lighting Functions.)
 

Global Illumination

The ability to evaluate indirect illumination models using radiosity or other global illumination techniques. (See the section on Illuminance and Illuminate Statements.)
 

Area Light Sources

The ability to illuminate surfaces with area light sources. (See the section on Light sources.)
 

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.