Problems of traditional pipelines solved by USD

I read a little bit on USD and think getting the basic gist of it. However, I struggle to identify which problems of traditional pipelines based on interchange formats like alembic get solved by USD?
When do pipelines become non-linear?

Thanks for your input!

Also curious to know more about it.

But so far the main pro of USD is that unlike FBX it’s an open format. For example right now while it’s possible to use Blender in gamedev it’s not optimal because it uses Collada instead of FBX SDK, which presents some… quirks when exporting to game engines. Blender can’t use FBX SDK because of license restrictions (on the side of Blender).

USD adoption would solve that, as Blender would be able to integrate it.

This will be a long post, but here goes.
This will mostly be about the pros of USD since I struggle to think of anything Alembic can do that USD cannot.
For background, I’ve been using Alembic at various levels for the last six years and USD at a fairly in depth level for the last two and a bit years.

  1. Alembic has limited composability.

Alembic only supports instancing and with 1.7, some form of overriding with layered alembics but that’s really where it ends. There’s also not much in the way of tooling for layered alembics, mainly because it came as studios were shifting to USD.

Meanwhile USD supports many forms of composition, including layers, references, instancing, overrides and variants.

This means you can create scenes where you reference multiple assets in, change materials on them and override any attribute.

  1. USD is extensible

When you use USD, you can create plugins for it to do things like represent your own data types, read other data formats or have asset resolvers.

A good example is that USD can read alembic files but expose them as if they were USD to begin with. So it means you can use many different file formats without needing to know the API for each one, or making importers , as long as someone writes the plugin.

For custom data types, it means you can define your own types in USD with their own API. For example your game engine may have something unique to it like a collision type. You can make this a concrete type in USD so you’re not having to try and figure out if a mesh is a regular mesh or a collision object.

In the case of custom resolvers, it means that you don’t need to use just regular file paths in USD. If your studio uses shotgun, or some other asset tracking system, USD can refer to those paths in their native format ie a url etc…

  1. Alembic has fewer things it can represent

Unlike Alembic, USD can describe anything from materials, character rigs, lights, node graphs etc…

  1. USD is easier to use as an API

If you ever have had to interact with the Alembic API, it can be pretty gnarly. USD has a much nicer and simpler API to use.

  1. USD can be read by humans

Alembic only has a binary representation. USD has both a binary and text representation. You can convert between them so if you need to debug something, you can just open USD in a text editor.

  1. USD can be packaged up

With a .usdz file you can package up your entire scene and share it. So all your textures, Scene, etc…

And you can read this file like any other usd file without needing to extract it.

  1. USD is viewable in augmented reality

Without doing any work, you can load a usd file on any iOS device and view the models in AR. It’s a small thing for many studios, but it’s great to see your assets that way and potentially use them to review it.

  1. USD comes with Hydra

Hydra is a rendering middle man layer that lets you render any scene backend with any renderer, provided they have written the integration.

By default it comes with support for a USD backend and an OpenGL renderer called Storm, but you can just as easily render the same scene with Karma, 3Delight, Embree, Radeon pro render, etc… by just installing a plugin and switching a toggle.

There are quite a few more advantages to using USD but I won’t go in to them. Instead I’ll mention the biggest disadvantage:

It’s relatively newer and support for it across applications is limited unless you’re willing to compile plugins yourself.

That said, it is gaining massive amounts of support quickly with many film studios making the jump, and the big off the shelf game engines getting support.

By next year most of the big applications in this space will have USD support built in natively.


At a very basic level you can think of USD as Photoshop Layers for 3D data, plus the composition possibilities of software like Substance Designer, Nuke, etc.

Every alteration, including component level edits, could be stored in a separate file that one artist could publish to without blocking another. This network of data/edits could then be inherited, overwritten, and/or grouped into variants.