The Process of Generating Scene Graph Data

As mentioned earlier, the real core of Katana is that what we want to render is described by a tree of filters, and that these filters are designed to be evaluated on demand. We're now going to look in a bit more detail at how Katana generates scene graph data.

The main interface that users have is the Node Graph tab. They create a network of nodes to specify things like Alembic files to bring in; create materials and cameras; set edits and overrides; and they can create multiple render outputs in a single project. The parameters for nodes can be animated, set using expressions, and manipulated in the Curve Editor and Dope Sheet views. The Node Graph can have multiple outputs and even separate disconnected parts, and it has potentially different parameter settings at any time on the timeline.

When we want to evaluate scene data, such as when doing a render or inspecting values in the UI, the nodes are used to create a description of all the filters that are needed. This filter tree has a single root, and represents the recipe of filters needed to create the scene graph data for the current frame at the particular node we are using for output.

It is this filter tree description that is handed to output processes such as 3Delight or Renderman. For the geekily inclined: this is actually done by handing a serialized description of the filter tree as a parameter to the output process, for example, a string parameter to a render procedural.

The actual generation of scene graph data is done by using this description of the filters to create scene graph iterators. These are then used to walk the scene graph and access attribute values at any desired locations in the Scene Graph tab. This approach of using iterators is the key to Katana's scalability and how all scene graph data can be generated on demand.

Using the filter tree, the first base iterator at /root is created. This can be 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 also 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 are used while rendering are called as the user expands the scene graph and inspects the results. This allows the user to inspect the scene graph data that is generated at any node for the current frame. TD's can use the UI as an IDE for setting up filters in a visual programming approach, and then running those filters to see how they affect the generated scene graph data.

The APIs are covered in more detail later, but the main API to create and modify the node graph is the Python NodegraphAPI, and the main one to create new filters is the C++ Scene Graph Generator API.