The Alliance for Open Universal Scene Description (AOUSD) recently announced its two-year roadmap. This plan charts the organization’s path toward becoming a global standard for interoperability of disparate data types, describing 3D scenes and environments across industries. AOUSD’s Core Specification (Core Spec) Working Group led the development of this roadmap, with the goal of formalizing the foundational data models and predictable behaviors of OpenUSD composition and population in normative specifications.

AOUSD’s Core Spec working group will define the foundation of OpenUSD, clarifying how low-level data is structured and interpreted. The working group will ensure both portability and interoperability across software platforms and devices. This strong foundation will enable developers and users of a tool or platform supporting OpenUSD to use OpenUSD data in a predictable, consistent manner.

Below, we’ve included an overview of the roadmap both as a technical blog and a video session, which provides visuals to accompany some of the more technical concepts. 

 

Normative, Multi-Part Data Specification

Our approach is to start with a normative, multi-part data specification at the most low-level aspects of OpenUSD.

This encompasses data models as an abstraction of system inputs that are agnostic of software runtime specifics like APIs and other programming-language, and device-dependent considerations.

These system inputs yield predictable behaviors in canonical outputs encompassing the full complement of composition sites that can contribute opinions and populate the scenegraph hierarchy from which predictable data queries can be performed from any USD-compliant platform.

OpenUSD Specification “Layer Cake”

AOUSD will build upon the foundations being laid by the Core Spec Working Group as part of a longer-term roadmap to continue building out a full multi-part specification for all USD data models.

Like a layer cake, higher-level specifications may normatively reference the core spec. Some of the next levels of the layer cake can include specifications for composed data such as meshes and materials and on top of that, computed data such as visibility, and specifications for compliance with OpenExec.

Timeline of Core Spec Deliverables

The initial timeline of Core Spec deliverables spans 2024 and 2025.

We aim to publish preliminary outlines for all specification areas in the first quarter of 2024, and then submit preliminary drafts for formal review around the third quarter of 2024.

Revisions addressing feedback will be published in the fourth quarter of 202 and be iterated upon with a goal of final ratification around the third quarter of 2025.

A future goal is to work with the ISO JTC1 PAS submission process to allow international adoption and recognition of the core specification.

Guiding Principles

To execute the approach, our guiding principles are to specify predictable behavior for generating the full complement of composition sites ordered by LIVRPS (the acronym for OpenUSD’s composition arcs in strength order: Local, Inherits, Variant sets, References, Payloads, Specializes) strength, which can contribute opinions to each prim on the stage, and the resolved values for all metadata, including attribute values and relationship targets, on the populated stage.

Multi-Part Core Specification Areas

The multi-part core specification consists of 5 interrelated areas: Foundational Data Types, Foundational Data Models, Core File Formats, Composition Engine, and Stage Population.

Foundational Data Types

The Foundational Data Types area of the specification defines attribute value types.

These include straightforward scalar types such as floats and doubles, as well as USD-specific value types such as asset paths serving as resource identifiers.

Dimensioned types encompass tuples such as double2, and linear algebra types such as a 4×4 matrix of doubles, or an array of floating-point triples serving as point coordinates.

We have posted a preliminary draft of this section here, to illustrate the low-level approach we are undertaking to begin building out the multi-part core specification as a layer cake from the bottom up. 

Foundational Data Models

Foundational data models, which include the document model and composition schema defined in OpenUSD’s informative SdfSchema implementation, where Sdf stands for scene description foundation.

These include, for example, the fields required to represent a prim spec, that is, a single scenegraph node, in an individual document, or layer in USD parlance, and the canonical input fields to the composition engine, such as the reference field, represented as a listop to prepend and delete reference arcs on an individual prim spec, and so on.

In addition, this area of the normative specification will describe the queries required to be supported by USD-compliant file format frontends, as outlined in OpenUSD’s informative SdfAbstractData class.

Core File Formats

The Core File Formats embody concrete manifestations of the abstract Foundational Data Models, specifically in human-readable USDA, and binary USDC with support for optimization features such as data deduplication and direct memory mapping.

While packaged USDZ is not a core file format, we are keeping it in scope, as the contributors with the relevant skill sets for specifying USDZ overlap greatly with those specifying USDA and USDC.

Composition Engine

A normative specification for the composition engine encompassing the LIVRPS strength ordering algorithm will draw informative inspiration from OpenUSD’s Pcp library, where Pcp stands for prim cache population. 

In particular, the testPcpCompositionResults unit test harness within the Pcp library serializes the entire span of composition sites for a given input USD root layer. Those inputs are covered by test cases in OpenUSD’s PcpMuseum include a wide range of representative datasets covering common and corner cases to exercise the composition engine. A normative specification of the composition engine will cover at least the cases embodied in the PcpMuseum. That is, the specification will completely normatively describe the behavior of the composition engine, using the predictable behavior of the testPcpCompositionResults for PcpMuseum as inspiration.

Another specification exercise inspired by Pixar’s history is to undertake a potential informative reference implementation of LIVRPS as a literate programming exercise.

Stage Population

Finally, the Stage Population area of the core specification will be a normative description of the behaviors required to populate the composed scenegraph to comply with predictable data queries for all composed prims, properties, and metadata.

This includes the population of prim definitions such as those defined by USD schema plugins and many user-facing aspects of the previous four areas, such as namespace mapping across composition arcs as well as layer offsets and scales.

Summary

In summary, the Core Specification Working Group is formalizing normative abstractions of informative implementation details based on existing code and documentation to ensure portability of USD data across platforms and devices as well as interoperability to grow existing data ecosystems and aggregate previously siloed data.

If your company is interested in joining the Alliance for OpenUSD, sign up to become a member. Check out the AOUSD website to learn more about the organization and what membership entails. Follow AOUSD on Facebook, Instagram, LinkedIn, X, and YouTube. Get support and join our community of artists, designers, and developers in our forum.