...
In RenderMan, there are different ways to choose how your object and its instances will render. These are conveniently divided in the node. An explanation is below along with links to the relevant settings.
The Attributes Section allows for variation among instances.
:
| Section | Description |
|---|---|
attributes | Attributes which can be varied across instances (e.g. |
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. |
traversal | 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.
PrmanObjectStatements: attributes
| Include Content | ||||
|---|---|---|---|---|
|
The primAttributes are obeyed for all instances.
...
PrmanObjectStatements: primAttributes
| Include Content | ||||
|---|---|---|---|---|
|
PrmanObjectStatements:
...
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. E.g 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 then you'll only have one Geolib runtime cooking location and so would see only a single print from that Op at "/root"
primvars
Name | Type | Default | Description |
|---|---|---|---|
| falloffpower | float | 0 | Falloff 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 there are tools available 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. |
The first tool is an attribute to control the depth of parallelism in your scene: forceSerialIn part this is the reason we have provided the object setting "prmanStatements.traversal.forceSerial". When you set that attribute 'true' on a location then the traversal will switch to serial at that location and all child locations will be run in a single thread.
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, branches 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 . 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. We have typically found the default to be good enough, but unforeseen scene configurations may benefit from serial processing and so the option exists.
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 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.