Introduction to OpenExec (as of April 2025)

An overview of OpenExec, which has finally been merged into OpenUSD

#openusd #openexec
Contents

1. Introduction

This article summarizes information about OpenExec, which was merged into the OpenUSD dev branch in April 2025. It assumes that readers have a basic understanding of OpenUSD. Please note that OpenExec has only just been merged and is still at an early stage of development. The information in this article is current as of April 2025 and is highly likely to change in the future. Also note that OpenExec is not an out-of-the-box solution. It is foundational technology provided as part of OpenUSD and is not intended to accomplish anything on its own.

OpenExec originated as the core evaluation engine of Presto, Pixar's proprietary DCC application. The project aims to bring that evaluation technology into today's OpenUSD. It brings not only static scene description to USD, but also dynamically computed values. It is described as:

  • an engine for general-purpose computation
  • capable of resolving dependencies
  • based on a dataflow graph
  • using sparse invalidation (a mechanism that recomputes only the parts that need it)

Together, these capabilities enable computations to be performed efficiently and optimally.

Information about OpenExec remains limited. In this article, I provide an overview based on materials published by Pixar engineers and on the code that was merged into OpenUSD.

2. References

This article refers to the following materials and source code:

The discerning reader may wish to load these materials into NotebookLM and use it as an aid to understanding (which may be faster than reading this article) .

3. OpenExec Overview

The following is summarized from page 26 onward of https://openusd.org/files/BOFSiggraph2023.pdf:

OpenExec is:

  • a general-purpose computation engine with caching and invalidation mechanisms
  • a system that supports custom data types and custom computation callbacks, allowing arbitrary logic to be implemented
  • a way to feed “derived values,” in addition to “authored values,” back into a scene

OpenExec is not:

  • a system for procedurally creating or deleting namespace
  • a rigging system (although such a system can be built on top of it as a foundation)

Its key characteristics can be considered from the perspectives of real-time evaluation, scalability, and USD integration.

3-1. Real-Time Evaluation

OpenExec uses a computation graph to evaluate changes in its inputs and reflect the results in real time. In Presto, this real-time evaluation mechanism reportedly made it possible to work smoothly with complex scenes and interactive operations—for example, Luca Paguro's transformation into a sea monster in Luca. By incorporating OpenExec, it should become possible to significantly shorten preview and iteration times, providing foundational technology for more intuitive and efficient workflows.

3-2. Scalability

OpenExec is designed to scale efficiently to large scenes and complex computations. As demonstrated by Presto's crowd workflows, OpenExec can deliver high performance even in scenes containing large numbers of objects. This is likely because OpenExec tracks dependencies and provides caching and invalidation mechanisms that recompute only the portions affected by a change. OpenExec may allow CG engineers to handle large scenes and complex simulations—tasks that have traditionally been time-consuming—within more practical timeframes.

3-3. Possibilities Enabled by USD Integration

OpenExec is not a standalone project; it is provided as part of USD. This means that dynamic values can be handled within USD scenes. For example, it becomes possible to configure an attribute on one prim so that it is driven dynamically by the values of other attributes in the scene. Because OpenExec supports custom data types and custom computation callbacks, custom computational processes can also be integrated flexibly within the USD framework. Furthermore, USD aims to become an industry standard. Integrating OpenExec into USD should improve its versatility and interoperability, enabling it to be used across a variety of DCC applications and pipelines.

Details of Presto's execution-system architecture have been presented at past SIGGRAPH events, and its underlying technologies are expected to carry over into OpenExec. Presto's execution system is divided into three phases—compilation, scheduling, and evaluation—and was designed with efficient parallel processing in mind. Integrating such a proven execution engine into USD could enable more powerful and flexible scene description and execution, and it is expected to play an important role in future CG production pipelines.

4. Examining the Architecture and Implementation

In this section, we will read through the actual code and examine how OpenExec is organized.

Gemini 2.5 was used extensively to help interpret the code in this section, while Claude 3.7 Sonnet and OpenAI o3 were used extensively during the writing process.

Let us begin by looking at the organization of the OpenExec source code. OpenExec is implemented in the pxr/exec directory and is divided into the following modules:

  • pxr/exec/exec: Core system API
    • Core APIs for request management and dependency-graph construction (system.h, request.h, compiler.h, and others)
  • pxr/exec/vdf: Low-level execution engine (Value Definition Framework)
    • Low-level dependency-graph representation, scheduling, and parallel execution engine (network.h, schedule.h, parallelExecutorEngine.h, and others)
  • pxr/exec/ef: Page-based caching and execution (Execution Framework)
    • Higher-level execution foundation: the executor itself, dependency caching, and leaf-node management (executor.h, dependencyCache.h, leafNode.h, and others)
  • pxr/exec/esf: Scene abstraction interface (Execution Scene Framework)
    • Scene abstractions for stages, objects, and attributes (stage.h, object.h, attribute.h, and others)
  • pxr/exec/execUsd: Bridge implementation between USD and OpenExec
    • Bridge to USD scenes that adapts USD objects to the ESF interfaces (sceneAdapter.h, stage.h, prim.h, and others)

The main entry points are:

pxr/exec/exec/system.h          # Main system API
pxr/exec/exec/request.h         # Creation and management of computation requests
pxr/exec/execUsd/sceneAdapter.h # USD adapter

High-Level Architecture

OpenExec has the following layered architecture:

+-------------------------+
|      Application        |
+-------------------------+
           ↓
+-------------------------+
|    OpenExec (exec)      |
+-------------------------+
       ↙         ↘
+----------+   +----------+
|    ef    |   |   esf    |
+----------+   +----------+
     ↓              ↓
+----------+   +----------+
|    vdf   |   | execUsd  |
+----------+   +----------+
                    ↓
              +----------+
              |   USD    |
              +----------+

  1. Scene data layer (USD → esf → execUsd):

    • OpenExec accesses USD scenes through the ESF abstraction interfaces.
    • execUsd wraps USD objects and adapts them to these abstraction interfaces.
      • This allows OpenExec to interact with scene data and manage computations and dependencies.
    • Changes to scene data propagate through the ESF layer to the EXEC layer.
      • This makes it possible to detect changes and trigger recomputation or cache invalidation.
      • Managing these processes in the esf / execUsd layers allows them to propagate into dependency-graph construction and computation requests.

  2. Compilation layer (exec):

    • Processes computation requests.
    • Compiles computations into a network of nodes.
    • Creates a VdfNetwork representing the computation dependency graph.
    • Manages the topology of the computation graph.

  3. Execution layer (vdf → ef):

    • vdf provides the low-level execution engine.
    • ef builds higher-level execution services on top of vdf.
    • Handles scheduling, execution, caching, and invalidation.

Coordination and Data Flow Between Layers

Data moves between OpenExec's primary layers as follows:

  1. exec: Receives computation requests from clients and constructs a VdfNetwork dependency graph.
  2. vdf: Manages the graph representation and scheduling information (VdfSchedule), then passes them to the parallel execution engine.
  3. ef: Manages execution through EfExecutor and LeafNodeCache, enabling caching and partial execution.
  4. esf/execUsd: Provides input data through the USD scene abstraction and bridge.

Conclusion

OpenExec represents an important step toward standardizing and optimizing computation within the USD ecosystem. Although it is currently an experimental feature with limitations, its design and foundation have the potential to evolve into an extremely powerful computation framework.

By providing a unified approach to computation based on scene data, OpenExec is expected to expand the range of USD applications and enable more complex and advanced workflows. As development progresses, richer features, performance optimizations, and improved ease of use should make it a valuable tool for a broad range of users.

Appendix

Although not directly related to OpenExec, the following information about other software may also be useful: