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.
- 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.
- 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…
- Alembic has fewer things it can represent
Unlike Alembic, USD can describe anything from materials, character rigs, lights, node graphs etc…
- 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.
- 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.
- 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.
- 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.
- 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.