Key Concepts

A recipe in Katana is an arrangement of instructions - in the form of connected nodes - to read, process, and manipulate a 3D scene or image data. A Katana project can be made up of any number of recipes, and development of these recipes revolves around two tabs: the Node Graph and Scene Graph tabs.

Within the Node Graph tab, Katana utilizes a node-based workflow, where you connect a series of nodes to read, process, and manipulate 3D scene or image data. These connections form a non-destructive recipe for processing data. A node’s parameters can be viewed and edited in the Parameters tab.

To view the scene generated up to any node within a recipe, you use the Scene Graph tab. The scene graph’s hierarchical structure is made up of locations that can be referenced by their path, such as /root. Each location has a number of attributes that represent the data at that location. You can view, but not edit, the attributes at a location within the Attributes tab.

These key concepts are explained in greater depth in the Quick Start Guide.

An Example Recipe

In this example of a very basic recipe:

• the Node Graph tab contains the recipe for creating the scene,

• the Scene Graph tab shows the scene generated at the beauty node (a renamed Render node),

• the Parameters tab shows the current parameters of the GafferThree node,

• the Viewer tab shows a 3D view from the point of view of the camera.

The User Interface

Katana allows you to create recipes for filters, using a familiar node-based user interface (UI). In the UI, you 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 you can inspect the results of filters on a controlled sub-set of the scene.

The way you 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. If you are accustomed to conventional 3D packages that have a single 3D scene state, it may 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 you open up the scene graph hierarchy in the UI. Complexity is controlled by only executing filters on locations in the scene graph that you have expanded.

A scene does not need to be entirely loaded in order to be lit. In Katana, you create recipes that allow scene data to be generated, rather than directly authoring the scene data itself. It is only the renderer that needs the ability to see all of the scene data, and then only when it needs it. Katana provides access to any part of the scene data if you need to work on it. You can set an override deep in the hierarchy, or examine what attribute values are set when the filters run, but you can work with just a sub-set of the whole scene data open at a time. This is key to how Katana deals with scenes of potentially unlimited complexity.

Note:  As Katana uses procedurally defined iterators, it's possible to define an infinitely sized scene graph, such as a scene graph defining a fractal structure. An infinite scene graph can never be fully expanded, but you can still work with it in Katana, opening it to different depths, and using rule-based nodes to set up edits and overrides.

Note:  Katana 2.x uses an application-wide Qt style sheet to apply font preferences to Qt widgets. Custom widgets that use font metrics before widgets are shown need to be modified to add QWidget.ensurePolished() calls before working with QtGui.QFontMetrics instances.