The RenderMan Interface - Paul Bourke
The RenderMan Interface - Paul Bourke
The RenderMan Interface - Paul Bourke
- 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