...

The table below shows which commands may be specified inside a RiMotionBegin-RiMotionEnd block. If the Motion Blur capability is not supported by a particular implementation, only the transformations, geometry, and shading parameters from t0 are used to render each moving object.

Moving Commands

...

Resources

Resources generally encapsulate some part of the graphics state, or other information specific to the renderer such as a in-memory RIB archive. Resources are always named and have a type associated with them. Resources are unique in that they can exist outside the rest of the graphics state, and are thus not subject to standard scoping rules; instead, they have their own scoping block mechanism. An example of a resource is the ability to save the entirety of the current attribute state, and restore it at a future point, independent of the current attribute stack.

...

The following table describes which parts of the graphics state are manipulated by "string subset". In addition, PRMan allows for multiple subsets to be combined using comma separated lists. Hence, restoring the "shading,geometry" subset will be the same as restoring both the "shading" and "geometry" subsets.

• Note

  PRMan currently has limitations related to user attributes and scoped coordinate systems: user attributes or coordinate systems whose values are overridden while in anAttributeBegin-AttributeEnd scope may not save the correct value (the last value set in the current scope will be restored). In other words:

  AttributeBegin
     Attribute "user" "string mytex" ["grass.tex"]
     Resource "grass" "attributes" "string operation" "save"
     Attribute "user" "string mytex" ["flowers.tex"]
  AttributeEnd
  Resource "flowers" "attributes" "string operation" "save"
  Resource "grass" "attributes" "string operation" "restore" "string subset" "shading"
  

  When the named attribute state "grass" is restored, the attribute user:mytex will contain flowers.tex, not grass.tex. This limitation may be addressed in a future release.

...

The second resource's lifetime is scoped by the ResourceBegin and ResourceEnd calls and stores attribute state: green color and marble surface. Hence due to the scoping, references to "foo" within the ResourceBegin/End block will resolve against the second resource (green, marble). After the ResourceEnd, the second resource has been destroyed and the first resource is again in scope, and hence references to "foo" will resolve against the first resource (red, plastic).

...

Conditional Evaluation

RiIfBegin ( RtToken expression )
RiElseIf ( RtToken expression )
RiElse
RiIfEnd

These calls form the basis of a simple conditional evaluation mechanism that allow RIB archives to be constructed with a degree of context sensitivity.

Normally the elements in a RIB archive are selected by the application that is authoring the archive. Complex logic and data manipulations are properly the domain of a true programming language with RenderMan Interface binding. When RIB variations are needed in these cases, they are regenerated by the authoring application.

However, sometimes a previously generated RIB archive is reused in a different context and it may need some internal ability to adapt to each context. These RIB archives allow chunks of "frozen" geometry or scene state to be stored and then accessed from a higher level "driver" RIB file. The archive can be reused from multiple places in the same frame or across multiple frames. For example, an object whose shape remains the same across many frames might be placed in an archive, it's position and orientation might be animated by specifying a different transformation matrix in each per-frame driver file before referencing the object's archive. This modularity has many benefits, including the potentially large savings in per-frame RIB generation time when the archived object is very complex.

There are situations in which it is very useful to allow certain internal aspects of an archive to be altered based on the current external driver file state or parameters. For example, the archive might select entirely different surface shaders depending on which "rendering pass" is active. The driver file might define the current pass with a user Attribute setting:

Attribute "user" "string renderpass" ["shadow"]
Procedural "DelayedReadArchive" ["archive.rib"] [0 1 0 1 0 1]

Then, the archive can use the conditional evaluation calls to decide which shaders to apply:

AttributeBegin
IfBegin "$user:renderpass == 'shadow'"
   Surface "null"
ElseIf "$user:renderpass == 'beauty'"
   Surface "rmarble"
Else
   Surface "plastic"
IfEnd
Sphere 1.0 -1.0 1.0 360.0
AttributeEnd

Similarly, a single archive might be used by several versions of the renderer, such as during testing or when an asset is shared between productions. The "$renderer" namespace provides a "version" object with several useful values: major, minor, and build.

IfBegin "$renderer:version.major >= 21"
    Bxdf "simple/PxrHair" "hair" "color diffuseRootColor" [1.0 0.5 0.25]
Else
    Color [1.0 0.5 0.25]
    Surface "plastic"
IfEnd

Expression syntax:

The conditional expressions evaluated by IfBegin and ElseIf are similar to those found in C and many scripting languages. The entire expression evalutes to a numeric result, and if the result is non-zero then the associated branch of the If-Else block becomes active. The expression operators work on values that are string or numeric literals, or renderer state variables. A typical set of arithmetic, relational, and logical operators are provided, plus a few additional functions:

State variable names are looked up by searching the Attribute stack, then the Options, then RendererInfo. The search can be restricted by prepending an additional "namespace" qualifier:

$Frame                        -->   finds the Option (current frame number)
$limits:eyesplits             -->   finds the Attribute
$Attribute:limits:eyesplits   -->   also finds the Attribute
$Option:limits:eyesplits      -->   finds the Option

Traditional static archives will continue to be the right choice in most situations. With proper archive "factoring" the creator of the driver file can select appropriate archives as needed and hardcode their names in the driver. Conditional evaluation becomes useful when factoring isn't possible or when it can help reduce the number of required archives

RIB BINDING

 IfBegin expression
 ElseIf expression
 Else
 IfEnd

EXAMPLE

Using Computed Variable Names (i.e. $(subexpression)) in a conditional RIB statement. The use of computed variable names is similar to evaluating expressions created from the contents of other variables (like performing 'eval' or 'expr' from some shells).

prman x.rib main.rib ---> renders a yellow matte sphere

prman y.rib main.rib ---> renders a magenta plastic sphere

x.rib


Attribute "user" "string abc" ["x"]


y.rib


Attribute "user" "string abc" ["y"]


main.rib


 ##RenderMan RIB
 version 3.03
 FrameBegin 1
 Format 128 128 1
 Display "/tmp/t.tif" "tiff" "rgba"
 Projection "perspective" "fov" [45]
 WorldBegin
 LightSource "distantlight" 1 "from" [1 1 -1]

 Attribute "user" "float x1" [11]
 Attribute "user" "float x2" [12]
 Attribute "user" "float y1" [101]
 Attribute "user" "float y2" [102]

 AttributeBegin
 Attribute "identifier" "name" ["mysphere"]
 Translate 0 0 2.75
 IfBegin "$($abc$Frame) > 100"
 Color 1 0 1
 Surface "plastic"
 Else
 Color 1 1 0
 Surface "matte"
 IfEnd
 Sphere 1.0 -1.0 1.0 360.0
 AttributeEnd
 WorldEnd
 FrameEnd