...
RenderMan for Katana supports three approaches to instancing: leaf-level instancing, hierarchical instancing, and instance arrays. The first approach, leaf-level, lets you instance matching pieces of geometry via an attribute. The second and third are very deliberate approaches where you set up an object master prototype and then explicitly instance it. The teapots_instancingExample.katana file includes an example of how to render the above image using these methods.
| Note | ||
|---|---|---|
| ||
Instancing can save on memory but may impact performance such as time to first pixel (how quickly a render begins sending pixels) since Katana may process many nodes. Options where you can instance a hierarchy will be more efficient for time to first pixel but you may lose control of some attributes you may wish to override, this is the trade off. In the PrmanGlobalStatements you can specify You can read more about nesting versus flattening on the main Instancing page. Essentially, the SceneGraph flattening time corresponds to the number of instances multiplied by the number of locations below the instance source. The more complex your instance sources are and the more instances you have, the greater the cost of flattening becomes. |
...
You may find that your scene is taking a lot of memory, and you think that because your scene has lots of repeated geometry, that you may be able to take advantage of instancing. The leaf-level instancing approach can be used to efficiently turn already existing geometry locations into instances of each other via the instance.ID attribute. RenderMan for Katana will make the first location it encounters with a certain instance.ID into the geometry masterprototype, and all subsequent locations will be instances. All locations with matching instance.IDs must be identical, otherwise there could be undefined behavior depending on which location RenderMan for Katana encounters first. The screenshot below shows an example of how to set the instance.ID attribute via an AttributeSet node.
...
In this approach instance source/object masters prototypes are called out via their Scene Graph locations and are then referenced in to their instance locations. This approach is good if you want to instance a hierarchy of locations.
...
- Change the "type" of the Scene Graph location to be used as the object master prototype to "instance source". Note that the Scene Graph location for the instance source must be a group. If you change the type of a geometric primitive to "instance source", then RfK will not have any information about the primitive type, and the instances will not render.
- Create locations for your instances. This can be done with a LocationCreate node or via an OpScript. If you want your instance source to be visible, you must also create a new instance for that as well (by contrast, the instance.ID approach will automatically make your instance source visible).
- Set the geometry.instanceSource attribute of each of your instance locations to be the Scene Graph location of your instance source
- Set the transforms on the instance locations using a Transform3D node or an OpScript.
...
The steps to set up the instance source locations are the same as in hierarchical instancing. Simply set the type of the group representing the object master prototype to "instance source". Then you will need to create a location of type "instance array" on which you will build up your instance array attributes.
These are the attributes required on the instance array location:
| string geometry.instanceSource | The array of instance source locations referenced in this instance array. |
| int geometry.instanceIndex | The instanceIndex attribute has one element for each instance in the instance array. Each element maps to an index in the geometry.instanceSource attribute. This mapping determines which instance source is used for each instance. |
| double or float geometry.instanceMatrix | For each instance in the instance array there are 16 values in the instanceMatrix representing the instance's transformation matrix. Note that this transform is relative to transform of the instance array itself. |
Additionally, there are some optional attributes available:
| int geometry.instanceSkipIndex | A list of indices in to omit from the instance array. Used to prune out certain instances. |
| group geometry.arbitrary | While formatted as constant PrimVars, these attributes become user attributes in the renderer. There should be an element in the value and indexValue attributes for each instance in the instance array. |
See this instanceArray.zip example (also available in RfK's Examples directory) for an example of how to set up an instance array from a point cloud.
...
Shading overrides can be accomplished in multiple ways. In the example file, a simple approach is taken where a completely new Bxdf is assigned to each instance. Fancier ways to vary the shading on each instance are possible with RenderMan for Katana. One such approach is to create a unique "user" attribute per instance. Within your master materialthe material assigned to the object prototype, you would create a PxrAttribute pattern that reads the user attribute, and then use the output to drive one of the parameters on the Bxdf.
While you can vary Bxdfs, transforms, light linking, and attributes per instance, there are some things that cannot be varied. PrimVars and parameters under the "primvars" and "primAttributes" groups in PrmanObjectStatements cannot vary per instance. Displacement also cannot vary across instances because it changes the representation of the geometry master prototype in the renderer. For a more in-depth discussion about instancing, please read the Instancing page in RenderMan documentation. It provides some great background information as well as the full list of what can vary across instances.
...