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:
Attributes which can be varied across instances (e.g.
Per-primitive attributes which are considered "master" properties (referred to in the table below as "Primitive Variables")
Constant per-primitive attributes which are part of the primitive definition. These cannot be varied per-instance.
|RfK 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.
|falloffpower||float||0||Falloff power for point primitives.|
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).
|forceSerial||int||0||Force traversal to serial processing for this and child locations.|
|evictHere||int||1||Prevent sibling eviction at this location.|
|flattenInstanceSource||int||2||Flatten hierarchical instance source locations.|
The first tool is an attribute to control the depth of parallelism in your scene:
For example, take a scene:
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"
The second tool we have for parallel traversal efficiency is the
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.
The last tool is the
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.