“Any” Attribute Type

An Extended Attribute that can accept values or connections with any legal attribute type.

Action Graph

An Action Graph is an OmniGraph that triggers actions in response to a particular event.


A property of a node or node type that consists of a name, a data type, and a set of metadata that defines further properties.

Attribute Data

The actual value an attribute has been given for a specific node and Graph Context.

Attribute Type

A description of the data type an attribute can hold. In many cases it is a simple piece of data such as float, int, or double, but it can also be more complicated data like a “Union” Attribute Type or a Bundle.

Authoring Graph

Refers to the definition of an OmniGraph structure, including nodes, attributes, and connections.


A Bundle is an attribute comprising of a set of named attributes, including other bundles.


The backwards-compatible interface surface defined by an extension. It consists of a set of interface classes, each of which comprise a set of static functions that are defined by an interface implementation.


A layer on top of the C++ ABI that provides a higher level interface on top of the low level ABI interface functions to make it easier to interact with the C++ code.

Compute Graph

“Compute graph” is a synonym for OmniGraph, an engine for programmatically manipulating scenes with a graph-based visual scripting interface.


An edge in the Graph that joins two Nodes, indicating a relationship between the two Nodes, usually that the downstream Node cannot evaluate until the upstream Node has completed evaluation. Generally speaking the connections are formed between two Attributes on the Nodes, not between the Nodes directly.

Dynamic Attribute

A Dynamic Attribute is an Attribute that is added to a node at runtime, as opposed to the ones that are predefined as part of the node’s ogn definition.

Execution Graph

The intermediate representation of an OmniGraph that has been optimized for fast evaluation, and which follows the business logic needs of a specifically defined Authoring Graph.

Extended Attribute

A type of attribute that is allowed to accept or produce more than one type of data.


The underlying data model that houses the data used by the Execution Graph during evaluation. It also provides the synchronizing of data between the CPU, GPU, USD, and external processes.

Generic Graph

The term Generic Graph is also referred to as a Push Graph, which evaluates every node at every system update, or “tick”.


The abstract concept that comprises nodes and connections which could be referring to either the Authoring Graph, the Execution Graph, or the combination of both.

Graph Context

Each time a Graph is evaluated it is done so using specific evaluation context, represented concretely by the graph context. Different contexts maintain their own separate data models with unique values for every node and attribute evaluated in their context.


An instance is a virtual copy of a Graph that can be replicated multiple times without actual replication of the Nodes within the Graph. Used for optimization of computation for duplicate subsections of a Graph by avoiding having multiple copies of the {term]Authoring Graph and Execution Graph.

Lazy Graph

A Lazy Graph is an OmniGraph that only evaluates nodes whose inputs have changed since the last evaluation.


Metadata is named general data that describes traits of either attributes or node types. It is a more flexible representation of object traits as it can have any data type and any name so that it can be attached to these objects at runtime.


A node is the basic vertex type in a Graph. It implements a single unit of computation and provides a location for attribute data storage and endpoints for graph edges, or Connections.


A JSON format schema that defines the structure of an OmniGraph node.


An engine for programmatically manipulating scenes with a graph-based visual scripting interface. It provides a platform for building graph types that potentially have very different types of authoring and evaluation representations. OmniGraph can represent such diverse graph types as state machines, AI training, and extension updates within Kit. It can be thought of more concretely as a graph of graphs that comprise the entirety of the graph authoring and evaluation system. Also used as the Prim schema type used for the USD representation of a graph.


The Prim schema type used for the USD representation of a node in a graph.

USD Prim

A USD term indicating the primary container object in USD.


A USD term indicating a namespace object in USD, like a Prim, but with real data. Roughly equivalent to the OmniGraph node Attribute.

Push Graph

A Push Graph is an OmniGraph that evaluates every node at every system update, or “tick”. It is convenient to use, but potentially inefficient as values are recomputed even when they are not changing.

Python API

The Python modules that are officially supported as the interface between OmniGraph and the rest of the development environment. Generally speaking if a Python symbol can be imported and its name does not begin with an underscore (_) or dunder (__) then it is part of the supported Python API. Otherwise it is unsupported and subject to change without backward compatibility.

Python Bindings

A subset of the Python API that is a Python wrapper on top of the C++ ABI. For the most part the functions that appear in it will be similar, other than following Python naming conventions, with a few extra additions that make a function more “Pythonic”, e.g. by supporting a generator.

“Union” Attribute Type

An Attribute Type that can assume a fixed set of types, as opposed to the “Any” Attribute Type, which can assume any type at all.


Universal Scene Description (USD) is the fundamental representation for assets in Omniverse, and the persistent backing for OmniGraph nodes.


A variable in this context is a value that is globally available at any location in a Graph without requiring an explicit Connection.


The process of evaluating an algorithm in parallel on multiple data sets of the same type. In a Node you can see the difference between regular evaluation and vectorized evaluation as the difference between implementing the compute function versus implementing the computeVectorized function.