Katana contains a robust approach to lighting, rendering, and assembling scenes for animation and VFX. A Katana "scene" is more properly called a recipe, as it doesn't really store much data itself, but rather the instructions and references necessary to build a scene for rendering.
There are four major areas of the organization in the Katana user interface:
|Macro view||Detail view|
Each area has a dedicated tab in the user interface.
As each node executes, it modifies the scene graph to reflect the action taken by the node. A node may add or remove scene graph locations, add/remove/modify attributes on existing scene graph locations, or even change the type of a given scene graph location (e.g., change a
polymesh to a
subdmesh by changing the type attribute). Nodes have many tools at their disposal for making changes, such as the CEL expression language, lua scripts, python scripts, and so forth; much of Katana is dedicated to providing flexibility and power for the nodes to do their job efficiently.
A node can be considered an operation where the scene graph changes based on a prescribed set of rules. After each node, the entire scene graph may be different.
Node parameters are a set of data that tell the node how to operate. Each node type has a specific set of parameters and based on the value of a parameter it may update its user interface to provide even more options. For example, in the case of setting a shader on a material node, it then reads the shader parameters and presents them to the user to change those as well.
The scene graph represents the current state of the world, represented hierarchically. There are a few special parts of the hierarchy: the geo, lights, materials, and procedurals. Scene graph locations broadly fit into those categories and are stored under those groups in a hierarchy.
Each scene graph location is simply an object that contains attributes. There are a couple of special attributes: name and type.
The name, combined with the names of the parent locations up the hierarchy forms the full named path to the location, e.g.,
/root/world/lgt/light is a named path to one of the lights we've created.
The type suggests the interpretation and minimal set of attributes the scene graph location contains; for example, a polymesh location will have at least the following structure:
P (3D positions)
vertexList (for each face vertex, these are the indices into the P array)
startIndex (the starting index in
vertexList for each face; there is one entry for each face, plus an extra at the end pointing one past the end of vertexList to signal the end of the list of faces).
By convention, each type of scene graph location should have a minimum set of attributes to be that type. You should play around with Katana's existing examples to see what attributes are required or are desirable for each type (for example,
subdmesh can have many more meaningful attributes). All scene graph locations may also contain whatever attributes you desire for your purposes; there are no restrictions on what you can put on them.
Katana is designed to be as fast and efficient as possible, even with scenes that scale into the range of millions of objects, billions of polygons and particles, and so forth. It is possible to shoot yourself in the foot if you do not manage your data carefully, but nonetheless, Katana provides a solid approach to dealing with complexity. The main concept in Katana is "lazy loading", where nothing is evaluated until it is asked for or needed. As of Katana 2.0v1 and newer, much of that processing can also happen in parallel on multiple cores, allowing scalable and efficient scene processing.
For example, the scene graph stays collapsed to the "root" by default. If you do not expand the scene graph at all, even with millions of objects Katana should stay quite responsive because you never asked to see what was inside the scene. The viewer will also not show anything in the scene you have not expanded in the scene graph. As you expand scene graph locations, it will only load just the level you asked for, and only the necessary attributes of those objects.
Additionally, the state of the scene graph is only what the currently viewed node says it is, so you may restrict your view of the scene graph to just what a particular part of the node graph will create. When evaluating nodes, Katana's API is such that it will ask for just a piece at a time, so the ops (katana operations) and scene graph generators will only have to do the most minimal amount of work possible.
Next, each scene graph location generally has associated with it a bounding box, so when viewing or rendering Katana will only load those scene graph locations (and associated attributes) whose bounding box is visible. In the case of Arnold, being visible requires that a ray actually hit the bounding box. To support this feature, when Katana launches the renderer it conceptually creates a very simple stub file for the renderer (of course, a .ass file in the case of Arnold), and puts a Katana procedural in there with very little else. When rendering begins, inevitably the Katana procedural will be invoked, and it will then begin creating child procedurals for the next level of the scene graph with their tighter bounding boxes. As some of those are intersected by rays they will be expanded, and Katana will continue the process of only loading what is asked for.
The art of Katana is knowing how to minimize what is needed, and working with the smallest/fastest set of data you can at any given time. In this manner, Katana can scale to immensely complicated scenes, still, stay responsive, and let the renderer deal with only what it determines is necessary. Arnold and Katana work very well together in this regard.
Node Creation Menus and Hotkeys
Two pop-up menus are available for easily creating Arnold nodes in the node editor (default hotkey shift+Z) and Arnold shading nodes (default hotkey alt+Z). You can enable/disable the menus, change hotkeys, and even menu colors with the environment variables:
KTOA_SHADER_COLOR_THIRD_PARTY. See the README file for more information on the environment variables.