User guide

16
Katana's initial focus was on RenderMan, particularly how to harness the power of RenderMan's recursive
procedurals. In a RenderMan procedural it is possible to perform arbitrary creation of scene data on demand, but
their full capabilities are rarely exploited.
The Katana approach is to have a single procedural powerful enough to handle arbitrary generation and filtering.
Essentially a procedural given a custom program in the form of a tree based description of filters. At render time,
Katana's libraries are called from within this procedural to calculate scene data as the renderer demands it.
Scene Graph Iterators
The key to the way Katana executes, filters, and delivers scene data on demand, is that scene data is only ever
accessed through iterators. These iterators allow a calling process (such as a renderer) to walk the scene graph and
examine any part of the data on request. Since that data can be generated as needed, a large scene graph state
doesn't have to be held in memory.
In computer science terms, it is the responsibility of the calling process to maintain its own state. Katana provides a
functional representation of how the scene graph should be generated, that can be statelessly lazily-evaluated.
At any location in the scene hierarchy Katana provides an iterator that can be asked:
• What named attributes there are at that location?
• What are the values for any named attribute (values are considered to be vectors of time sampled data)?
• What are the child and sibling locations (if any)?
An understanding of Katana iterators is key to writing new Katana plug-ins to generate and modify scene data.
Understanding how scene data is calculated on-demand is important for understanding how to make good, efficient
use of Katana. In particular, how input file formats, such as Alembic - which can supply data efficiently, on demand -
are potentially much better to use with Katana than formats that have to load all data in one pass.
The Katana User Interface
Katana allows users to create recipes for filters, using a familiar node based user interface (UI). In the UI the user can
also interactively examine the scene at any point in the node tree, using the same filters that the renderer runs at
render time (but executed in the interface).
When running through the UI, filters are only run on the currently exposed locations in the scene graph hierarchy.
This means the user can inspect the results of filters on a controlled subset of the scene.
The way users can view the scene generated at any node is similar to the way users of 2D node-based compositing
packages can view composited frames at any node. For users accustomed to conventional 3D packages that have a
single 3D scene state it can be a surprise that there is essentially a different 3D scene viewable at each node. Instead
of the scene graph being expanded as rays hit bounding boxes it is iterated as the user opens up the scene graph
2 KATANA FOR THE IMPATIENT | SCENE GRAPH ITERATORS