I would like USD to succeed. What can help?
If you don’t yet know what USD is, that is totally understandable. It stands for ‘Universal Scene Description’, and it’s a file format Pixar created over a span of many years and movies, and was released open source to the public in 2016. Though that’s not an entirely accurate description, and there will be a lot more of that in the rest of this post. For example, if you were to google ‘What is USD?’ you will hit a familiar issue when you try to discuss the file format with those who are not familiar with it, especially if they’re from North America:
The google result of “what is USD?"
USD has been used in Pixar’s movies, such as Toy Story 4, but also in movies like Spider-Man: Homecoming, Thor: Ragnarok and Birds of Prey. It has proven useful, and has been used for many years in pipelines for movies and offline rendering. For real-time rendering, I have not seen it used that much yet, but I can guess many studios are trying to move over to it. DDCs like Maya, 3dsMax, Houdini, etc, are all getting USD workflows slowly but surely integrated into them, so the way is being paved for everyone to use it.
So what does that mean? Will most people who work with 3D move over to USD? And would that, by extension, mean it will be the file format of the metaverse? I think so.
But there are a lot of problems in getting to a point of universal usage of USD. If you are a professional in the videogame space, the VFX space, the medical field, architecture, AR/VR, or anything else that uses 3D, you may have already heard of USD, but do not yet have an understanding of what it is. However, often even the folks who are working with USD right now often do not have a fully scoped idea of what it is, and what it can do. If you don’t understand USD, that’s not your fault. It is a fault we can rectify though, as a community of 3D professionals.
How? By clearly, frankly, and honestly breaking down the current barriers of entry. I’d like everyone to use USD, as it surely would help us get towards better tooling too, and I deeply care about a good user experience in tooling. If everyone were to use USD, we could perhaps have a similar user experience through all tooling to work on USD! Wouldn’t that just be magical? Having the same paradigms, mental workflows, and muscle memories across DCCs for USD?
So let’s go over some issues. What is holding back USD?
1. Documentation
USD is currently hard to learn and understand. If you go to the documentation website, it will immediately talk about API, layers, variants, base, usd, etc. Now you might say “Wait, an API? I thought this was supposed to be a 3D file format?”, and that is one of the issues here. You can also go to the other documentation website, which looks a bit more friendly. Neither of those two pages has any pictures or shows any hierarchies though, which are critical in understanding how USD works, and what it does.
If you then head off to the USD Terms and Concepts page, you will see so many terms that you will have a hard time understanding which are the important basic ones. They’re alphabetically ordered, so there isn’t any clue as to where to start. If we click the first one there, ‘Active / Inactive’, we read this:
”Activation is a metadatum/behavior of prims that models a “non destructive and reversible prim deletion” from a stage . Prims are active by default, which means they and their active children will be composed and visited by stage traversals.”
I wish you good luck understanding any of that when you are new to USD. There are so many more terms, underlined there, that you would also have to know and understand, to be able to understand that sentence. For example, let’s try and understand ‘prims’ then, and its first sentence reads:
“A Prim is the primary container object in USD: prims can contain (and order) other prims, creating a “namespace hierarchy” on a Stage, and prims can also contain (and order) properties that hold meaningful data.”
And down you go through the spiral of USD terms. There is a chicken and egg problem here where to understand one term, you have to first understand many other terms. Where do you start? Unless you’re required to learn how this works for your job, you probably don’t. You’ll probably get stuck and bounce off.
For example, to explain what a prim is, you could describe it much more simply at first, which the original sentence hints at near the end. For example in my own words:
“Prims contain properties and data. They contain ‘stuff’, and each line in the hierarchy is a prim. A prim could be a mesh, a material, a link to a texture, a spline, a light, etc, just as what you are used to if you’ve worked with hierarchies before."
Is that fully and always completely true? Does it cover all technical aspects? No, but it explains it in a way that makes sense to a human being. It reminds me of a quote from Richard Feynman in the documentary Fun to Imagine. He is asked how magnets work:
“I can’t explain that attraction in terms of anything else that’s familiar to you. For example if we said that the magnets attract like as if they were connected by a rubber band, I would be cheating you. Because they are not connected by a rubber band. [...] But I really cannot do a good job, any job, of explaining a magnetic force in terms of something else you’re familiar with, because I don’t understand it in terms of anything else that you’re more familiar with.”
Yes, that explanation of a prim isn’t everything it really is, but it makes it understandable to anyone familiar with 3D concepts. Starting off explaining concepts that way isn’t a bad thing. I think it’s much better to use basic terms to quickly describe how USD works, just as much as it’s better to quickly and easily explain magnets with rubber bands rather than with the mathematical details about the magnetic fields and electrical forces.
2. Nomenclature (Naming)
As shown earlier, googling about USD most often gets you information about the United States Dollar. There are more issues such as these, for example, let’s go back to the prim. Prim is short for primitive. You may think “Ah! A primitive! So like a primitive as we usually know it in the 3D world, for example a cube, a sphere, a pyramid, etc?” Again we’re back at: Yes, but not really. If you’re thinking about the cube, sphere, pyramid, etc, the basic primitives of 3D, then you would be talking about UsdGeom which is a schema that contains those primitives as for example UsdGeomCube, UsdGeomSphere, etc. But you may ask: “Wait, what’s a schema?” Okay, nevermind, there’s the chicken and egg problem again.
So a prim is short for primitive, but it’s not the 3D primitives as you may know them, it’s that they’re containers of data, properties, etc. That’s a bit confusing at first. Then we could get into other terms like stage, reference, payload, variant, etc, and again we’re getting into the deep end very quickly. To put things in much more simple, yet not 100% accurate technical terms:
A stage is the final 3D representation of all the loaded USDs.
A reference is essentially appending a whole or section of the hierarchy of one USD, onto a section of the hierarchy of another USD, in real-time when it is loaded on a stage.
A payload is a reference that you can decide to load at a later time, instead of immediately, when you load up a USD.
A variant is essentially a state. You can have multiple states active at the same time, and they can affect the same properties and prims. This can get complicated very quickly, but can also be used extremely simply, for example by having one state contain the entire hierarchy for a chair, and the other state containing the entire hierarchy of a table. Now you can switch between those two states, those two variants, and thus hierarchies, in real time when the USD is loaded. That’s powerful stuff!
I am not saying we have to change the names of things in USD! It’s much too late for that, and we’re stuck with them now. I think acknowledging that is the key: To honestly and earnestly tell people when they’re learning USD: “Hey, this is going to be confusing, but we’ll have to deal with this. If you have to ask me 3-4 times what something is, please feel no shame in doing so. I forget too, sometimes, when switching between the nomenclatures of different DCCs and APIs.” The amount of times I have seen folks be afraid of asking questions about USD, as if everyone is supposed to be an expert at it, is frightening. It is causing a limitation in the use of USD not for technical reasons, but social reasons. I don’t want that to happen. From my own personal experience: Even folks who have worked at Pixar for many years do not know everything there is to know about USD! And that’s fine. It’s just that big, and powerful, and adaptable. That cuts both ways.
There are tutorials out there that are getting better at explaining the basics, like for example the Nvidia course on USD. And Apple has released a video about the fundamentals of USD. But, we’ve not yet reached a clear and clean explanation that any 3D artist, designer, and producer can pick up, watch, and come out with a basic understanding. If USD is to become the format for everyone, as I hope it does, that has to be resolved. I want to help out on getting that done, hence this post, and more to come in the future.
One more example, to drive the nomenclature point home: In your 3D editor and pipeline, what is an Asset, an Entity, or an Object? Depending on what you’re familiar with, you will have different meaning behind each one of those, or the same meaning for 2 or even all 3 of them. I will write an other blogpost about that sometime, as it’s not only related to USD, but hopefully that gives you an idea of what an issue naming can be.
3. 3D tooling isn’t prepared yet
USD was released, but great 3D tooling that allowed everyone to edit and create USDs in a simple way wasn’t released. Some tools were released, but command line tools for 3D work is very 1990s. Additionally, when you go to the USD tutorials on the Pixar documentation website, your very first task is to read and understand a python script, then run it. It can make you believe you have to understand python to be able to work with USD, which is definitely not the case.
As mentioned earlier, there is an incredible amount of concepts at play for USD. Being able to edit all those different features on a USD, and using them in appropriate, fast, and easy-to-use ways, does not exist yet. It is possible, just not easy. Some other times, USD isn’t a first class citizen yet. 3dsMax for example does not come with USD out of the gate, and you have to download the tooling for it separately for ‘USD’ to show up as an export option. There is no information in the export window of it being missing though, so you may not know that until you google it.
Maya and Houdini are getting better at USD, and especially Houdini is getting a good grip on it. However, to then build a USD requires the user to first understand Houdini, which is a momentous task as difficult and time consuming as it is to understand USD. You have to build a hierarchy using nodes? Each node has properties and affects the other nodes, and you have to set them up to make sure the hierarchy and 3D representation of the hierarchy make sense? It’s a whole different way of building content that most folks are not used to. It’s powerful, Houdini achieves amazing results, and I think we can all agree it takes a while to learn.
Next to that, USD files reference each other. A USD file for example could reference an other USD file, or even a prim in that USD file, and it does so by looking at the location and name of that USD file. So you could have a USD file try to reference something like:
“…art/assets/furniture/chairs/chairwood/chair_wood.usd/MyAmazingMeshPrim”.
If you were to move or rename any of those folders, that referencing will break. If you rename the USD, the referencing will break. If you sneeze too hard while working on a USD in a DCC and accidentally hit your keyboard adding a letter to a prim, the referencing will break (That one is not a joke, it actually happened to me, and I had to spend some time debugging it to find out where in Houdini I accidentally added a letter to a field.) Undoing those broken references, and renaming files, and allowing the DCC access to your folder structure, whether it be on your local machine, or a server, does not yet exist as a good workflow. Currently, mistakes are heavily punished in USD, and if you wish to debug something, you better hope the tool tells you what is wrong. For now, it usually doesn’t.
And of course, depending on the tool, a USD may load in seconds, or in hours. For example Aras has done some really cool work to make the Moana scene, that Disney released, be able to load faster in Blender. But 4 hours to 10 minutes is a pretty gigantic gap. Similar issues can be found with Animal Logic’s ALab scene, where in USDView it may take ages to load, or crashes, while in Houdini it loads up nearly instantly. I think that one has something to do with whether the tool respects the USD concept of ‘purpose’ or not, but it also creates a question of how purpose should then be used, which I’ll get into more later. Either way, I am super grateful for Aras and Animal Logic for doing this work, as it allow us to see the issues, and show there are solutions!
Of course we can say that users shouldn’t have to debug USD at all, and all USD tooling should just automatically fix USDs, but, let’s take one step at a time?
4. It’s adaptable (Yay!) (Oh no!)
Anyone can make anything with USD. It’s Universal Scene Description, after all. And I truly do believe it is universal! That is, if you have the time to work it into doing what you want it to do. It is currently not easy to learn how to create new prim types or schemas. But first, I’ll have to explain: There are prim types, and each type contains a different set of default values, for example you could create a ‘Chair’ type, and say that it should have ‘4 legs’ as a value by default, so that if someone uses a ‘Chair’ type prim, they would always start off with a value saying it has 4 legs, and then they can adapt that if they’d like. That value could then be used by your tool to generate the correct amount of legs, for example. How do you define which types exist, and which values exist on types? With a schema, in which you can tell it what types should have what values according to that schema. Again, a simple explanation that may not be 100% accurate, but you get the gist.
Anyway, if anyone can make schemas and types for their specific use of USD, that’s super powerful! They can solve any problem they have, and define it and save it into their USD in ways that their tooling understands!
It also means that if you were to share that USD file to someone else, without sharing your schema and tooling, then they would not see the same result as you. Here is where we put the obligatory XKCD comic that we all know and love/hate. USD as a format is a new standard, and we should use it, but we do stand a risk of it being so adaptable that inside USD itself we could have multiple competing standards. At least we’d all be using USD, and that sounds like an improvement already, but it would be a lot better if schemas and tooling could be shared easily with the USD files in some way that other tooling can read them and display them correctly no matter what is unique about them. That is much easier said than done, of course, but it’s an issue we have to be honest about, and talk about, if we want to tackle it, as many folks thankfully already have.
5. What is a good USD?
You have created a USD. It uses all the default schemas and nothing custom. You want to share this USD with someone else, so they can view and edit it too. You send it over, and they still have trouble grasping it and editing it. Why?
Because a hierarchy can be built almost any way you’d like! That’s really powerful, as it allows anyone to build things the way they like. They can also name prims any way they like. So opening up a USD can often be like opening up someone’s .PSD, if you’re familiar with Photoshop. You better hope that the previous person has named all their layers correctly, and organized them in folders and subfolders if there are hundreds of them, because otherwise you are in for a world of hurt to edit that file at all. The same goes for USD. And with the previous points in mind of documentation, nomenclature, and tooling, you can see how this creates a tenuous situation.
There is no way everyone in the 3D space will agree on a single naming convention, and so I also do not believe everyone will agree to one way of building and organizing a USD hierarchy. For example, should materials be underneath a scope, or an xform? Probably a scope, as it has no transform values, but you can place materials underneath an xform, and USD won’t stop you from doing that. That’s just one example, of many.
And what about skeletons, animations, meshes, etc? Should they be saved separately, and referenced or payloaded in? Where should purpose be used, and where not? A huge power of USD is that giant compositions can be made up out of hundreds of USDs, so that each individual USD can be opened, edited, saved, and then committed separately in your favorite version controlling software, such as Git, or Perforce.
We won’t get to a world-wide agreement, and that’s fine to acknowledge, but trying to get to one isn’t a bad thing either. I am very happy some folks have been posting their work, so everyone can get an idea of how a USD’s hierarchy can be constructed.
USD is going to change the game
I hope at this point you’re not thinking ‘Oh no, this all sounds pretty bad…’, because USD is really neat! I haven’t even mentioned all the other awesome USD features, such as PointInstancers, overs, opinions, sublayers, usdc, usda, and usdz! There is so much more out there that is fantastic about USD. I’ll write another blog post in the future about those USD concepts, with simple explanations, and visuals that accompany those explanations. Because I think it is worth knowing about USD, and worth using, especially the better it gets over time.
At the same time, I think that vocalizing the issues out loud, and talking about them as a community, is what can move us forward just as much as creating better tooling and fixing bugs. Because how do we know what tooling to create for everyone to use, if we do not think about how a human being thinks about USD, about 3D content, and organizing that content? I’d like to see USD succeed. And together, as a 3D community, we can make that happen.
Video update (06-03-2024)
I have now also made a video that explains USD to a non-technical audience:
If this was interesting to you, and you’re at Devcom or Gamescom 2022, hit me up on Twitter @RYStorm. I’ll be there, and I love to talk about USD.