The PrmanObjectStatements is assigned to a specific location or group of locations and translates into prman as setting the state for an AttributeBegin/AttributeEnd block. This node allows you to do things like assign a subdivision approximation to objects to render smooth surfaces, apply a displacement bound for rendering displacements, and changing visibility flags and memberships.

 

In RenderMan, there are different ways to choose how your object and its instances will render. These are conveniently divided in the node:

SectionDescription
attributes

Attributes which can be varied across instances (e.g. lighting subset or camera visibility)

primAttributes

Per-primitive attributes which are considered "master" properties (referred to in the table below as "Primitive Variables")

primvars

Constant per-primitive attributes which are part of the primitive definition. These cannot be varied per-instance.

traversalRfK plugin controls for scene traversal.


The settings are listed in the tables below. Note that the tables do not currently line up exactly with the PrmanObjectStatements UI presentation of the parameters.

Attributes

PrimAttributes

Primvars

Name
Type
Default
Description
falloffpowerfloat0Falloff power for point primitives.

Traversal

As RfK traverses the Katana scene graph it will process locations in parallel and pass them to RenderMan for rendering. By default each new child location retrieved from Katana will spawn a new thread for processing. This default behavior is unlikely to give the optimal performance for any given scene, however PrmanObjectStatements includes settings for tuning the efficiency and the level of parallelism for a particular pipeline (e.g. your studio's standard Op Chain) or various types of scenes (e.g. many instances, many textures, many primitives, or perhaps all three).



Name

Type

Default

Description

forceSerialint0Force traversal to serial processing for this and child locations.
evictHereint1Prevent sibling eviction at this location.
flattenInstanceSourceint2Flatten hierarchical instance source locations.

Force Serial

The first tool is an attribute to control the depth of parallelism in your scene: forceSerial.

For example, take a scene:

/root/world/geo/pine_tree
/root/world/geo/elm_tree
/root/world/geo/oak_tree

with each tree location containing branches, leaves, roots, etc.

Ideally you traverse this in parallel at a high-enough level that it's not trying to do every leaf or every branch on a different thread. We do this in RfK by setting "prmanStatements.traversal.forceSerial" to True at the location where we want to stop processing in parallel. When that attribute is encountered during traversal RfK will switch to serial at that location and all child locations will be run in a single thread.

In the above example, setting "forceSerial" to true on "/root/world/geo/*_tree" means that each tree will be on a different thread, but all the contents of each tree will be serially processed in their respective threads. You'll need to evaluate your scene setup to see at what level it makes sense to force serial processing.

Each thread has it's own Geolib runtime containing per-thread caches of cooked locations. As a result all locations needed for any Op would to be cooked per-thread. Continuing with the above example: if you have three threads each looking at different locations under "/root/world/geo", you'll see "/root" cooked three times, "/root/world" cooked three times and "/root/world/geo" cooked three times. If you are running serial, or forcing the parallel traversal to one thread at "/root" then you'll only have one Geolib runtime cooking the location and so would see only a single print from that Op at "/root"

Evict Here

The second tool we have for parallel traversal efficiency is the evictHere setting. 

By default siblings of a Katana scenegraph location will be evicted from a thread's runtime memory when a location is processed for conversion to the Rix scenegraph. Setting this flag false prevents sibling eviction at this location in the event it is known that those siblings are best kept in the cache for subsequent access.

Flatten Instance Source

The last tool is the flattenInstanceSource setting.

Rather than changing the behavior to RfK's parallel traversal of the Katana scene, this setting improves RenderMan's traversal when building instances.  By default, RenderMan flattens an instance source into separate object masters for each geometric primitive in the group. This can get expensive as the number of instances increases or as the number of primitives inside the instance source increases.  Setting this option to Yes will tell RenderMan to keep this instance source location as a single object master.

This setting will override the global setting for prmanGlobalStatements.plugin.flattenInstanceSources - which can enable this setting on all instance source locations.