Create a ticket

Q100325: Katana Core Terms


This article gives short descriptions of the most important terms used throughout the Katana application and documentation.

Knowledge of these core terms will help users better understand the way Katana works and processes data, and enable them to make the most of the existing Katana documentation. This glossary of core terms can be used as a continuation and extension of the Key Concepts explained in the Katana Online Help.



  • Nodes: Nodes are the units used in the Katana interface to build the recipe for a Katana project. Nodes feature parameters that can be used to control their behavior. Nodes can be created and connected in Katana's Node Graph tab in the UI, and can also be modified via Python scripting using NodegraphAPI.

    Katana ships with many built-in types of nodes, but custom node types can also be created via Python scripting.

    There are two major groups of node types shipped with Katana: 3D nodes that produce scene graph that can be inspected in Katana's Scene Graph tab, and 2D nodes that produce images that can be viewed in Katana's Monitor tab.

    Nodes and their parameters effectively represent and control corresponding Ops that form Op graphs that are processed by Katana's geometry library to generate the scene data that can be viewed and inspected in Katana's Scene Graph and Attributes tabs.

    Please see the Katana Online Help for more information on Working with Nodes in the Katana UI.
    For working with nodes via Python Scripting, please see the relevant Working with Nodes section of the Katana Developer Guide.

  • Node graph: Node graphs in Katana are recipes of connected nodes that are part of a Katana project. The nodes in node graphs can be created and connected in Katana's Node Graph tab in the UI, and can also be modified via Python scripting using functionality from the NodegraphAPI Python package.

  • Parameters: Parameters are part of nodes, and typically control their respective node's behavior. Parameters of nodes can be edited in Katana's Parameters tab in the UI, by setting the edit flag on a node in the Node Graph tab, and can also be edited via Python scripting using parts of the NodegraphAPI. Values of parameters can be either constant, determined by Python expressions, or driven by animation curves.

  • Recipe: Recipes in Katana are node graphs of connected nodes that are part of a Katana project. Recipes typically represent the steps taken or operations performed to create 3D scene data in a scene graph, or the image manipulations performed to create 2D images that can be viewed in Katana's Monitor tab and written out to file.

  • Project: A Katana project is the sum of all the nodes and their parameters that form the recipes that are expressed in the project's node graphs. Projects are saved in Katana project files with the .katana file extension.
    For more information on working with projects, please see the Creating a Project section of the Katana Online Help.
  • Ops: Ops are the building blocks of operations that create and manipulate 3D scene data in Katana, and thusly produce the scene graphs that can be inspected at any point in a Katana node graph by setting the view flag on a particular node. Ops are instances of Op Types, which are plug-ins written in C++ that use a particular Katana API to define their inner workings: the Op API. Some functions available for C++ Ops are documented in the Katana Developer Guide under the Ops and OpScript section.

    Similar to the various node types used in Katana, Katana ships with many built-in types of Ops, but custom Op types can also be created via C++ programming and using the Op API.

    When the view flag on a node is set, the node is queried for its corresponding Ops. The behavior of a node in terms of the creation or modification of 3D scene data can be defined by a single Op, but can also be defined by a number of Ops arranged in an Op Chain or Op Graph.

  • Op Arguments: Op Arguments control the behaviour of Ops that define the effect of nodes in a Katana recipe. They roughly correspond to parameters on 3D nodes. When changing the parameter of a node, corresponding Op Arguments are updated, and the scene is recooked, if the node or any node downstream is being viewed (by virtue of having the view flag set on it).

  • Cooking - Cooking is the act of executing the Ops that correspond to nodes in the Katana recipe in order to create scene graph locations and their attributes which can then be viewed and inspected in the Scene Graph and Attributes tabs. When setting the view flag on a node in the node graph, the Ops that correspond to that node and all of the nodes above it (in the sense of being connected to it upstream) are executed/evaluated/cooked to produce the scene graph at that point in the node graph. In technical terms, the cook() function of each corresponding Op type plug-in is being called to create or modify locations in the resulting scene graph.

  • Filters: Filters are the old equivalent in Katana 1.X releases of Ops in Katana 2.X releases and above. They represent the building blocks of operations that create and manipulate 3D scene data in Katana 1.X releases.

  • Lazy Evaluation: One of the key aspects of Katana's processing paradigm is that operations are only evaluated when their results are needed. For example, the Ops that correspond to a particular node are only cooked when the node itself or a node downstream of it is being viewed (meaning it has its view flag set). In the context of the Scene Graph tab, data for scene graph locations is only produced when the scene graph hierarchy is expanded to reveal them in the tree view widget.

    When working with Katana's APIs, lazy evaluation can have an effect on the results of certain function calls. For an example, please see Q100358: How to query attributes of scene graph locations via Python using a Geolib3 Client.

    Lazy evaluation also applies to aspects of Katana's UI, where a mechanism named freezing and thawing ensures that the UI is only updated when necessary in response to user interactions.

  • Graph State: Katana maintains a Graph State data structure when traversing up the node graph. It contains information such as the current frame and the shutter timings, and is passed to Ops that are represented by nodes when cooking scene graph. Nodes can read from and write to the Graph State as part of identifying their inputs. For example, a TimeOffset node reads the current time and increments or decrements it by some amount, as controlled by its inputFrame parameter. The modified Graph State is then passed to the node above for cooking its Ops. It is important to realize that the Graph State information flows up the node graph, unlike scene data, which flows down the graph.

    Some Python functions to work with Graph State are documented in the Katana Developer Guide.

  • Graph State Variables: Graph State Variables (sometimes abbreviated as GSV) essentially allow users to define key-value pairs within the Graph State (see above), and can be set at the project or node level. They can then be referenced and manipulated by other nodes, allowing for a powerful workflow, where groups of nodes and entire node graph branches can be enabled and disabled with ease.
    For more information, please also see the Katana Online Help on Graph State Variables.

    Project-level GSV are known as Global Graph State Variables, and node-level GSV are known as Local Graph State Variables. The following types of nodes are available for working with and/or modifying local GSVs: VariableSet, VariableSwitch, and VariableEnabledGroup, and VariableDelete.

  • GenericAssign: GenericAssign is an advanced and powerful concept in Katana, in which parameters of nodes are associated with specific attributes on locations in the scene graph. Such parameters effectively control the values of their corresponding attributes, and their widgets in Parameters tabs are capable of showing values of attributes from the incoming scene, allowing users to inspect and modify those attribute values.

    An example of a node type that uses GenericAssign-based parameters is the RenderSettings node type. The parameters of RenderSettings nodes correspond to attributes in the renderSettings group attribute on the /root location in the scene graph. When setting a value of a parameter of a RenderSettings node, the corresponding attribute in the renderSettings group is set. When connecting a RenderSettings node to an incoming node graph, the widgets of parameters of the node show the values of the attributes they correspond to. State badges that are part of the parameters' widgets show the value states of the respective parameters, indicating whether the corresponding attributes are set to a specific value by nodes upstream of the node that is being edited (incoming value), or by the node itself (local value), or whether the attributes are not set to a specific value, in which case they use a default value instead.

  • Scene graph: 3D nodes that are part of Katana recipes produce a hierarchical set of data, called the scene graph, which can be interactively inspected in Katana's Scene Graph and Attributes tabs in the UI, and can be presented to a renderer or any output process. Examples of data that can be held in the scene graph can include geometry, particle data, lights, instances of shaders, and global option settings for renderers.

    For more information, please also see the Katana Online Help on Using the Scene Graph.

  • Locations: Locations are the units that make up the scene graph hierarchy. Many other 3D applications refer to these as nodes, but in Katana they are referred to as locations to avoid confusion with the nodes used in the node graph. Locations can uniquely be identified using their name and the names of all of their ancestor locations in the scene graph, which form a scene graph location path, e.g. /root/world/geo/pony.

    Some more examples of how to work with locations in the Scene Graph can be found under Scene Graph Basics and Manipulating the Scene Graph in the Katana Online Help.

  • Attributes: Attributes are containers for data held on locations in the scene graph. Examples of data stored in attributes are 3D transforms such as 4x4 matrices, vertex positions of geometry, and value settings for an instance of a shader. Attributes of a selected scene graph location can be inspected interactively in Katana's Attributes tab, but not edited, as their values are determined by nodes and parameters of the Katana project.

    Some examples of common attributes locations can have can be found in the Katana Developer Guide under Attribute Conventions. For more detailed information on creating, manipulating or deleting attributes, please see the chapter on Working with Attributes

  • Attribute Types: There are different types of attributes for different basic types of data: integer numbers, floating-point numbers, double-precision numbers, and strings. In addition to these types of data attributes, attributes can be grouped in hierarchies using group attributes. Furthermore, a special type of attribute, the null attribute, is used for specific cases, such as to declare a certain attribute as not set, so that a default value for the attribute is used instead.
Was this article helpful?

We're sorry to hear that

Please tell us why
14 out of 14 found this helpful