26.01.2015 Views

The RenderMan Interface - Paul Bourke

The RenderMan Interface - Paul Bourke

The RenderMan Interface - Paul Bourke

SHOW MORE
SHOW LESS
  • No tags were found...

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

• No attribute inheritance should be assumed unless implicit in the definition of the<br />

User Entity (i.e., within a hierarchy).<br />

• No attribute should be exported except to establish either global or local defaults.<br />

<strong>The</strong> <strong>RenderMan</strong> Specification provides block structuring to organize the components of a<br />

RIB file. Although the use of blocks is only required for frame and world constructs by<br />

the Specification, the liberal use of attribute and transform blocks is encouraged. A modeler<br />

enables a Render Manager to freely manipulate, rearrange, or delete scene elements<br />

(frames, cameras, lights, User Entities) by carefully bounding these elements in the RIB file<br />

according to scope. A Render Manager might, for example, strip all of the frames out of<br />

a RIB file and distribute them around a network of rendering servers. This, of course, is<br />

only possible if the RIB file has been structured in such a way as to bound those things<br />

pertaining to a given frame within its frame block and those things pertaining to all frames<br />

outside and before all frame blocks.<br />

User Entities<br />

A User Entity couples a collection of geometric primitives and/or User Entities with shading<br />

and geometric attributes. As such it introduces a level of scope that is more local than<br />

that implied by the <strong>RenderMan</strong> world block. Typically, the term User Entity refers to a<br />

geometric element within a scene whose attributes or position a user may wish to modify<br />

or tweak. Because there is some computational expense associated with attribute block<br />

structuring, there is an intrinsic trade-off between control over individual User Entities and<br />

rendering time/memory requirements. At one extreme, the entire scene is made up of one<br />

User Entity within one attribute block. At the other extreme, each polygon is a User Entity<br />

and the renderer is forced to spend most of its time managing the graphics state. Modeling<br />

programs and their users may wish to carefully weigh this trade-off.<br />

<strong>The</strong> Scoping Conventions above prescribe the following User Entity Conventions:<br />

• All User Entities must be delimited by an attribute block.<br />

• All User Entities must have an identifier attribute that uniquely characterizes that Entity<br />

to the user. Two special identifier attributes are provided to distinguish between<br />

Entities organized by a geometric relationship (the name identifier) and Entities organized<br />

according to material makeup (the shadinggroup identifier).<br />

• A User Entity must be completely described within its attribute block.<br />

Nonportable options and attributes<br />

<strong>The</strong> following list of RIB requests are restricted as they either limit the device independence<br />

of the file or they control rendering quality or speed parameters. Render managers<br />

should provide this kind of control to users at render time. <strong>The</strong> inclusion of these restricted<br />

requests by a modeler should indicate to a Render Manager that they are, in some sense,<br />

mandatory. When including nonportable options or attributes in the RIB file, they should<br />

be located contiguously (according to scope) in a RIB file.<br />

187

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!