User guide

It is this filter tree description that is handed to output processes such as RenderMan or Arnold. This is done by

handing a serialized description of the filter tree, as a parameter, to the output process. For example, as a string

parameter to a RenderMan or Arnold procedural.

The generation of Scene Graph data uses the serialized description of the filter tree to create Scene Graph iterators.

The iterators are used to walk the Scene Graph and access attribute values at any desired scene graph locations. This

approach - using iterators - is the key to Katana's scalability, and how scene graph data can be generated on demand.

Using the filter tree, the first base iterator at /root is created. This is interrogated to get:

• A list of the named attributes at that location.

• The value of any particular named attribute or group of attributes. For animated values there may be multiple time

samples, with any sample relevant to the shutter interval being returned.

• New iterators for child and sibling locations to walk the hierarchy.

This process is the same as used inside the UI to inspect scene graph data when using the Scene Graph, Attributes

and Viewer tabs. In the UI, the same filters and libraries that would be used while rendering are called. So when you

select and node, expand the Scene Graph, and inspect the results, you're looking at the Scene Graph data that would

be generated at that node, at the current frame. From a TD's perspective the UI is a visual programming IDE for

setting up filters, then running those filters to see how they affect the render-time Scene Graph data.

The main API to create and modify elements within the Node Graph is a Python API called NodegraphAPI, and the

main ones to create new filters are the C++ APIs Scene Graph Generator API, and Attribute Modifier Plug-in API.

Collections and CEL

Collection Expression Language, or CEL, is used to describe the scene graph locations on which an operation or

assignment will act. CEL statements can also be used to define "collections" which may then be referenced in other

CEL statements.

There are two different purposes that CEL statements can be used for: matching and collecting

Matching is the most common operation, and is used when scene graph data is being generated. Many nodes in

Katana have CEL statements that allow the user to specify which locations the operation defined by this node will act

on. For instance, CEL statements are used in the MaterialAssign node to specify which locations in the hierarchy will

have a particular material assigned to them. As each scene graph location is generated it is tested against the CEL

statement to see if there is a match. If it is a match then the operation is executed at that location. This matching

process is generally a very fast one to compute.

Collection is a completely different type of operation: a CEL statement is used to generate the collection of all

locations in the scene graph that it matches. Depending on the CEL statement this can potentially be expensive as it

may involve having to open up every location in the scene graph to see if there is a match. Collecting is usually done

as part of a baking process or to select things in the UI ('Collect and Select'), but also has to be done for light linking if

you are using an arbitrary CEL expression to specify the lights.

7 SCENE ATTRIBUTES AND HIERARCHY | COLLECTIONS AND CEL