Table of Contents |
---|
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.
...
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
Include Content | ||||
---|---|---|---|---|
|
...
PrimAttributes
Include Content | ||||
---|---|---|---|---|
|
...
Primvars
Name | Type | Default | Description |
---|---|---|---|
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 there are tools available 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 |
---|---|---|---|
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. |
...
Force Serial
The first tool is an attribute to control the depth of parallelism in your scene: forceSerial
.
...
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.