Date: Thu, 28 Mar 2024 12:45:51 +0000 (UTC) Message-ID: <1408490189.7450.1711629951860@ip-10-0-0-233.us-west-2.compute.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7449_1316920948.1711629951857" ------=_Part_7449_1316920948.1711629951857 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The RenderMan interface is designed to be a standard interface between mode=
ling programs and high-quality rendering programs. As such, it has provisio=
ns for the specification of 3-D scene descriptions that include: hidden sur=
faces, spatial filtering, dithering, motion blur, depth of field, flat and =
curved surfaces, objects, constructive solid geometry, and programmable sha=
ding to express lighting conditions, shadows, and surface appearances, with=
sophisticated control over color, texture, and reflectivity. The design of=
the interface emphasizes the ability to convey, compactly and efficiently,=
the information required to produce rendered images that resemble actual p=
hotographs.
What follows is a very general overview of the RenderMan Interface that = introduces the interface routines and terminology. It concludes with a brie= f description of how certain concepts that are common to 3D graphics are ha= ndled in the interface.
The RenderMan Interface was proposed by Pixar in May, 1988, as a standard i=
nterface between modelers and high-quality renderers. To date, it is the on=
ly proposed rendering interface standard that includes provisions for all t=
he features in a scene description required to synthesize photorealistic im=
ages.
At the time of its introduction, the RenderMan Interface was defined in = terms of a C language binding, a set of 96 C procedures that provides a com= plete rendering interface. Since then, a bytestream protocol has also been = defined and incorporated into the interface specification. This protocol is= known as the RenderMan Interface Bytestream (RIB), and it not only allows = a scene description to be stored as an ASCII or binary coded file but also = provides a means for transport over a network.
For the sake of simplicity, the interface will be presented here in its = C language form. The conversion to RIB is quite straightforward, and a full= description of it can be found in The RenderMan Interface, Version 3.1.
The RenderMan Interface describes a scene as a sequence of geometric primit=
ives. This sequence specifies all the objects in a scene in terms of the va=
riety of flat and curved surfaces that RenderMan supports. To control the p=
ositioning and shading of these objects, the RenderMan Interface maintains =
a graphics state, which is primarily just a current setting for each of a l=
arge number of parameters associated with the rendering of an object in a s=
cene.
The graphics state consists of options, attributes, and the interface mo= de. Options are the rendering parameters that affect how an entire scene wi= ll be rendered, while attributes are the parameters that can differ from ob= ject to object in a scene. The interface mode constrains and controls the c= ontext of allowed RenderMan procedure calls, and it also maintains the grap= hics state stack. This stack allows various parts of the graphics state to = be saved and reinstated at will.
To control the graphics state, there are procedures in the interface tha= t change the current mode, options, and attributes. These routines are clas= sified here as mode-changing procedures, option-changing procedures, and at= tribute-changing procedures. The interface also includes a set of geometric= primitive procedures that describe the actual geometry in a scene.
The interface starts up with default option and attribute values, which = are defined in the interface specification. Calling a RenderMan option- or = attribute-changing procedure sets the values of certain related options or = attributes in the graphics state.
A scene is begun by calling the mode-changing routine RiWorldBegin(), an= d its options are set from the option values in the current graphics state.= These values then become frozen, and it is forbidden to use any option-cha= nging procedures until the scene's description is finished.
In the scene, attributes are still free to change. Each piece of the sce= ne's geometry is described by calling a RenderMan geometric primitive proce= dure; a given primitive gets its attributes from the current graphics state= at the time it is passed through the interface.
RenderMan routines all have names of the form RiSomething(). They can be cl=
assified quite cleanly into the following categories:
Geometric Primitive Procedures
Mode-Changing Procedures
Option-Changing Procedures
Attribute-Changing Procedures
Texture and Bookkeeping Procedures
Geometric primitive procedures in the RenderMan interface place geometric p=
rimitives in a scene. They support polygons, bilinear and bicubic patches, =
non-uniform rational B-spline patches, quadric surfaces, and retained objec=
ts.
Procedures for changing modes are for basic renderer and scene control, = or to control special modes of the interface for retained object, CSG, and = motion blur specification. Though most modes also affect the attribute stac= k, there are modes for additional stack control.
There are also procedures for changing options. Each one sets a closely = related set of option parameters in the graphics state, and the majority of= them control either the effects that arise from the camera model or the di= splay processing that occurs in the renderer.
Procedures for changing attributes alter a related set of attribute para= meters in the graphics state. As attribute parameters pertain to operations= that occur on each primitive, they tend to affect either a primitive's geo= metry and positioning in space or its lighting, shading and the opacity of = its surfaces. Included as a geometric attribute is the current transformati= on, which defines the current coordinate system for all point values. Becau= se of the special importance of this attribute, there are specific procedur= es to manipulate the current transformation matrix, to concatenate nonlinea= r transformations into the current transformation, and to attach a name to = a coordinate system.
Finally, there are miscellaneous routines to produce texture map files f= rom image files and perform various bookkeeping tasks.
From the point of view of RenderMan Interface procedure calls, a shader is =
just the name of a compiled shading language file that exists in a known pl=
ace. However, shaders also have parameters that can be set through the inte=
rface when the shader is brought into the graphics state. To handle this ca=
pability, certain RenderMan procedures take a list of arguments known as a =
parameterlist. Each parameter has a default value that is given in the shad=
er, so it only needs to be in the parameterlist if it is to have a value ot=
her than its default. The parameterlist always begins after the last proced=
ure-specific argument, and it consists of an optional paired list of argume=
nts followed by the terminating token argument RI_NULL.
The paired arguments in the parameterlist each contain a token followed = by a pointer to an array of values. The token is just the string for the na= me of the parameter, and the values in the array are the values that get as= signed to the parameter. Since there are both point and color type variable= s defined in the Shading Language, it is possible for a parameter to have m= ore than one floating-point value associated with it. For this reason, the = rendering interface must know the type of every parameter appearing in the = parameterlist. The names and types of parameters that appear in the standar= d shaders are already known to the interface. However, nonstandard paramete= rs must be declared with the RiDeclare() procedure before they can be used = in a parameterlist. Altering a shader's parameters affects the shader's pre= sence in the graphics state, but it does not affect the shader itself. Ther= efore, every invocation of a given shader starts with the default parameter= values and alters them according to the parameterlist in the call.
The routines that invoke shaders are not the only RenderMan procedures that=
use parameterlists. RenderMan geometric primitive routines use them to def=
ine a variety of surface parameters in addition to position and shape, and =
RenderMan texture routines use them to specify optional texture parameters.=
There are also a few other routines that are designed to take extended set=
s of parameters using parameterlists.
Since the length of a parameterlist is not always known at compile-time, Re=
nderMan also provides a varargs form for each procedure that uses a paramet=
erlist. These routines have names of the form RiSomethingV(), and each does=
the same thing as its RiSomething() counterpart, taking a fixed number of =
pointers to variable-length argument arrays instead of a variable-length pa=
rameterlist.
Before leaving this introduction, it is worth noting how the RenderMan 3D g=
raphics environment works. In particular, it is important to know how Rende=
rMan handles coordinate systems, transformations, camera positioning, and l=
ight sources. Mentioned here are the primary graphics conventions in Render=
Man that are likely to differ from other 3D environments.
The natural RenderMan coordin=
ate system is a left-handed one in which the x-axis points to the right=
, the y-axis points up, and the z-axis points into the screen. For any geom=
etric primitive in a scene, RenderMan keeps track of several coordinate sys=
tems, including "object", "shader", "world", "camera", "screen", and "raste=
r" spaces. In addition, any coordinate system can be named with the RiCoord=
inateSystem() procedure. The interface starts up in camera space.
Before worldBegin() has been called, transformations are used to position t=
he camera by defining world space (see Camera Positioning, below). After Ri=
WorldBegin(), they set up the coordinate systems into which objects and sha=
ders are placed. Shaders have coordinate systems associated with them in th=
e same way that objects do. By interspersing RenderMan transformation and s=
tack routines between geometric primitive routines, it is possible to contr=
ol how object space is defined for each object in the scene. The same is tr=
ue for shader space, based upon where the call that invokes each attribute =
shader is made.
RenderMan applies given transformations onto objects in reverse sequence= . This means that the last transformation concatenated onto the current tra= nsformation before an object is defined is the first one that will be appli= ed to the object.
In RenderMan, the camera is not specified as a separate object. Instead, tr=
ansformation routines are called before RiWorldBegin() to define the mappin=
g from world space to camera space. This process is conceptually the same a=
s having a camera that is fixed at the origin, looking down the z axis, and=
transforming the world, as though it were an object, until it is in proper=
view.
RenderMan places light sources into the scene as shaders. The positioning o=
f a light source is set through parameters to the light shader associated w=
ith the light, and each light is included in the scene with a call to RiLig=
htSource(). Since any point values passed to a light shader are interpreted=
as being in the current coordinate system, it is also possible to use tran=
sformations to control light source positioning.