OpenUSD 26.11: scene object authorship records, PMC mesh compression and faster composition

The Alliance for OpenUSD has announced OpenUSD 26.11 and described the release's key features. The format gains a standard way to record who created each scene object: an artist by hand, an export from a DCC package or a generative AI step. For studios that already mix manual work and generated data within a single asset, this is a standard mechanism for tracking provenance right inside the file, without external spreadsheets and pipeline metadata.

The second major theme of the release is performance. Pixar measured the composition speedup on several production scenes. For those who ship heavy geometry over the network, OpenUSD gains support for the open PMC mesh compression codec.

Whose prim is this

The new authorship schema is attached to a prim and stores a record of who or what created it: the program and its version, the contributors, the type of source, the input data and the time of creation. A single object can carry several records. For example, a character was generated by a neural network, then refined by a modeller, and then the asset went through an export from another package. Each of these steps keeps its own record. Authorship also accumulates from parent objects, so a prim carries the context of its hierarchy along with its own records.

These records can be viewed with the new usdauthors utility, either for the whole scene or for an individual layer. Pipeline developers get a programming interface for the same queries. If a client asks before project delivery which assets were touched by AI, the answer can be looked up in the file itself — provided the records were written into it.

Faster composition, leaner Hydra

Composition no longer copies nodes that are subsequently discarded anyway. A separate optimisation concerns building the library itself: according to Pixar's measurements, it became shorter in Visual Studio and Xcode, while in GCC the build time barely changed.

"Pixar reports a 10–30 percent speedup in composition across several production scenes."

That is how the result is described in the Alliance for OpenUSD blog. The same post notes that the measurements relate to specific workloads and that the result depends on scene structure and build configuration. For comparison: in the spring release 26.05, composition optimisation yielded around 8% memory savings on individual computations in test shots and 17% in one of the reports. The current gain concerns speed.

Hydra, the layer that passes the scene to the viewport and render delegates, has learned to share identical constant data between related objects. In a test with a crowd of skeletal characters, assembled on the basis of a production scene, Hydra's memory consumption dropped by 25%. Large scenes will also benefit from parallel selection traversal, batched point-instancer updates and optional offloading of the scene index cache.

There is also a new setting for instances: an instance can be expanded in the render representation so that subsequent scene filters work with its hierarchy, while instancing in USD itself remains as it was.

PMC mesh compression

OpenUSD adds support for Polygonal Mesh Coding (PMC), a codec from the Volumetric Visual Media working group at the Alliance for Open Media. Alongside it come a format plugin for compressed meshes and the usdcrush command-line utility, which converts meshes in a USD scene. According to AOUSD's assessment, this gives teams distributing geometry-rich assets a way to reduce the storage and transfer volume of meshes. The component is optional and disabled in the standard build script, so it has to be enabled separately when building OpenUSD.

Storm: backplates and implicit surfaces

In 26.08, released on 20 July 2026, the backplate schemas — that is, plates behind the frame — appeared, along with their initial support in the built-in Storm renderer. In 26.11, backplates gain materials with time-based animation, non-illuminable materials and brightness grading. The grading parameters have been renamed in the process: gain became slope, lift became offset, gamma became power. Assets using the old names need to be updated.

In preview mode, Storm has learned to draw implicit surfaces natively. Previously this work concerned only spheres; now cones, cylinders and capsules have been added. Matthew Kuruc described the problem on the AOUSD forum back in April 2025: a sphere was turned into a subdivision surface, and after smoothing it "shrank" inside the specified radius. If such a sphere is used as a guide for collisions, the picture in the viewport diverges from what the simulation sees. Native drawing displays the supported shapes directly, without first turning them into a polygonal mesh, but for now it is off by default and is enabled with a separate experimental option. This option has replaced the previous one, which was responsible only for spheres.

What else has changed

• In RenderMan XPU 27.3, MaterialX implementation graphs extend native support for Standard Surface and OpenPBR. Integrations with RenderMan 27.2 and earlier versions need to disable this capability.
• A "duration" value type has appeared, separated from a point in time: shifting an animation changes its start but not its length. Files with such values will be read only by recent versions of the USDC and USDA readers.
• Variable expressions can specify a fallback value if the variable is absent from the context. An asset can set a default value, and the pipeline can override it.
• Automatic fixes for validators can now be registered in Python.
• Physics handles disabled rigid bodies in a hierarchy more consistently, so colliders and joints are interpreted more uniformly.
• Dependencies have been brought in line with VFX Reference Platform CY2025: oneTBB by default, Qt 6.11 on Windows, Linux and macOS, OpenImageIO 3.1.8, OpenColorIO 2.4.2, OpenVDB 12.1.1, OpenEXR 3.3.6.
• Binary files written by the earliest versions of the Crate format are no longer opened by the reader by default. The next group of old versions remains in deprecated status.

What this means in practice

The authorship schema arrives against the backdrop of the question of separating manual and generated work becoming ever more prominent for studios. The value of such a record will probably depend on whether DCC packages start filling it in on export. The schema in itself is a capability of the format: if the tool does not create records, the field will remain empty.

With PMC it is worth being more careful. The Alliance for Open Media opened the codec's reference implementation on 28 April 2026 and itself calls the standard forthcoming. Khaled Mammou, co-chair of the working group, said that developers can help shape the final specification. In other words, the format may still change. For internal data transfer and online asset delivery it can apparently already be tried out, while archiving production assets only in compressed form is risky for now. The fact that the component is disabled by default also points to a cautious approach.

Judging by the description, the studios that will benefit most from this release are those with large scenes and crowds: a gain in composition speed and savings in memory. Those who already have grading set up on backplates, and who still have very old binary USD files in their pipeline, will have to spend time on migration.

Why has OpenUSD taken up authorship tracking right now: the influx of AI generation, studios' rights requirements, pressure from regulators?