OpenUSD instead of GLTF: Notes of the USD Roundtable at GDC 2024
The topics discussed at this year’s USD roundtable were:
Do studios mostly use USD for authoring, or only for interchange?
Why do you use USD, and how did you convince your studio to use USD?
What is everyone’s experience of run time vs edit time performance?
Extending USD: Who does it, and why?
What is something you wish you knew about USD before you used it?
USD has a movie stigma. How do folks deal with that?
USDz, who uses it, why, and does anyone use it for mobile platforms?
For those who have never attended a roundtable: This is a room filled with mostly game developers, from both big studios and indie studios, as well as non-game developers from manufacturers, software houses, and service providers. The folks in the room ask questions, and then anyone in the room can raise their hand to answer those questions. This information is unfiltered, and not directly from me, so always take it with a grain of salt, as your own situation may vary.
If you would rather listen than read, you can also find this article in video form on my youtube channel.
1. Do studios mostly use USD for authoring, or only for interchange?
So the underlying question here is: Do studios built in different file formats and then export to USD for interchange, or do they build the content directly with USD and also use it for interchange? We polled the room for this. Not many were using USD, but the ones who did mostly used it for authoring. So if they use USD, they both build in it and use it for interchange. They do not just build in a different file format and then convert to USD for interchange. A few folks mentioned this was the main reason for using USD instead of GLTF: That the entire development of content in DCCs, in editors, and back and forth between all those editors can work in USD. USD can contain a lot of data within it. Folks build larges scenes with thousands of references, payloads, custom extensions, schemas, etc, in USD. That content can then be used and edited across many different DCCs. Basically: Studios like USD as it provides a single source of truth in any DCC that the USD content is opened in. So they use it for authoring and interchange purposes.
I think this generally makes sense to what they are advertised to be used as. GLTF compares itself as being ‘The JPEG’ of 3D file formats. In relation to that, I would say USD is ‘The PSD’ of 3D file formats, with layers, editing, and lots of data possible, with the ability to then also save it as ‘The PNG’ by using USDZ.
2. Why do you use USD, and how did you convince your studio to use USD?
There was a lot of interest in this question, which in my experience makes sense. Everyone is curious, but afraid to be the first to dip their toes in. Similar to what we currently see in the 3D editor space where folks want to move from Unity to Godot, and where they are wondering the same thing: Why do other studios use it, and how did they convince their studio to use it? As we say in The Netherlands: Everyone is '“Looking the cat out of the tree.”
I first polled the room to get an idea of how many folks do use USD at the moment, and from which companies they were. It was clear that USD was currently mostly used by larger studios. By larger I am grabbing a quick estimate of more than 300+ employees at the studio.
The main reasons that were brought up by those companies as to why they use it, and how they convinced their studios to switch were, in no particular order:
Compositions: You can compose scenes in USD, and reference between scenes to build larger content scenes from smaller content scenes, and smaller content scenes from individual pieces of content such as meshes, materials, animations, etc. It is one large tree of content. This is similar to how game development studios have always worked, but usually only in their own 3D Editors. So this tree system being made possible between many third party DCCs like Blender, Maya, 3dsMax, Houdini, was seen as a great improvement over existing pipelines and workflows.
Edits & Overrides: In the games industry we have long been used to being able to edit and override in larger scenes. Usually this requires the 3D editor to support it, and for final content in the final in-engine composition to be edited and overridden. Essentially it is the kind of non-destructive layering that folks are used to in general game development. In USD’s case, this can then be made possible in third party DCCs, and then used in Unreal, Unity, and in-house engines. This was seen as a big improvement over existing pipelines and workflows.
Good for custom engines: Many studios have their own in-house engines, and considering USD is open source, it can be more easily integrated within the exact pipeline and workflow needs that a studio has. Especially larger AAA studios have highly unique and special cases that they need to have resolved for their games, which requires unique cases for their 3D editors, and USD is adaptable to those situations, which was again seen as a big improvement over existing pipelines & workflows.
In my personal experience it’s always been the technical folks at a studio that you have to convince to use USD. Software engineers often do not like having to do more work, or not knowing how much work something is. In my experience this is because production will always ask them for estimates, and then if those estimates are wrong, they are the ones in trouble, even though trying to get estimates for building brand new software is like pulling a rabbit out of a hat. As in: You can convince someone into thinking that you know exactly how long something will take, as long as you have done it before and already prepared it. So in my opinion the reason that USD is not used as much yet is simply the sheer unknowns for technical implementation and specific unique cases, which then translates into unknowns for production time schedules, which is usually unacceptable for anything that needs time & funding. To be clear: I don’t think that is how production systems should work, but that is how it usually works at most studios.
3. What is everyone’s experience of run time vs edit time performance?
Folks in the roundtable mentioned that run time USD was mostly not used by them. Studios are using USD for edit time, and the moment they go runtime they still convert to an in-house data format that then allows them to run as smoothly as they would like to. So the USD is not queried in runtime, but converted into something that allows querying and performance.
One particular comment that came up is uncertainty of running USD on console architecture. Considering many games have to work on many platforms, such as Windows, Xbox, PlayStation, and Switch, there was a lot of uncertainty about running USD on those platforms, especially in regards to memory constraints. This was another reason to convert from USD to an in-house format when in runtime.
Also it was mentioned that Remedy did a great talk about conversion to runtime formats at GDC 2024 this year, though this content is behind the GDC Vault paywall, so you will have to log in with a subscription to view it.
4. Extending USD: Who does it, and why?
The answers were clear here: Those who use USD really like to extend it, they say it is easy to do so, and they say you can extend it exactly where you want. For AAA studios who have a lot of experience and need of customized file formats this is a very good thing that they were very happy about. However, it can be so easy to extend that you can end up with your own custom version of USD quite quickly, which can then make it difficult to interact with other tools, DCCs, and studios.
Some particular advice that folks in the roundtable mentioned was:
Dynamic layer stacks reduce perforce conflicts, and are great for prototyping.
Do not use local layers. For example where one is in version control, and the other locally. Destructive changes make this not viable and hard to debug.
Extending can give trouble, as Houdini for example uses vanilla USD, and there are a lot of different ways studios extend their implementation of USD. So everyone can end up with their own version of USD that nobody else can then easily use.
You need to ensure schemas are registered, and the way folks deploy them is automated based on the DDL.
Do not have your plugins depend on a shared library, as it results in dependency hell.
Also, Remedy did another great talk about USD schemas at GDC 2024 this year. Again this is behind the GDC Vault paywall, so you will have to log in with a subscription to view it.
5. What is something you wish you knew about USD before you used it?
A fantastic question, and I am so glad it was asked. One clear thing came up very quickly: Variants are bad, do not use them. Updates on them cause a lot of changes, there is little tooling that can edit it, and it is a lot of work to update them when any changes happen. I can personally attest to this as well, as the USD vehicle test assets I submitted to the ASWF GitHub are a massive pain to update in Houdini due to their heavy use of variants.
Some other tips that came up are:
Start with the ASWF standard for USD.
Join the ASWF Slack for discourse and meetings.
Look at the talks Remedy has done about USD.
It is hard to convert different materials, for example finding corner cases like missing a normal map.
Make sure the team understands what features of USD you are using. You have to teach USD to the team, and make them understand how it is supposed to work.
Houdini Solaris has a good USD editing environment.
USD workflows depend on about the tooling support. Maya and 3dsMax for example have large differences in what USD features they support, and the same goes for Unity and Unreal. Look at what kind of features you will use, and what editors you will use, to understand what is best for you.
6. USD has a movie stigma. How do folks deal with that?
At the moment, USD is mostly known for being used movies and VFX studios. Game development is catching up fast, but the nomenclature between game development companies and movie companies is often a barrier. ‘Stage’ vs ‘Level’ for example, or ‘ST’ vs ‘UV’. We also see USD used more and more in manufacturing, such as car manufacturing, so it’s definitely not just a movie format anymore. The stigma of it being a movie format may simply take time to adjust in public consensus. Behind the scenes, a lot of USD work is happening, with Remedy being the most public about their USD progress in video game development.
7. USDz, who uses it, why, and does anyone use it for mobile platforms?
Apple uses USDz more for runtime features, and it is a portable way to transfer data, including to mobile platforms. Reality Composer Pro is also a 3D editor made by Apple. (Disclosure: I worked on Reality Composer, Reality Converter, and Reality Composer Pro as a tool designer, but I no longer work at Apple.).
Someone brought up that they use Reality Composer Pro with USD as an authoring format, and then covert to USDz at the end. The editor was also mentioned to be made for Vision Pro, so its use cases may be more specific to that area of AR/VR.
Thank you
I was great fun to host these USD roundtables for the first time this year. We had a lot of good discussion about many topics folks were wondering about. As I host this roundtable during the full duration, I do not have the time to write notes at the same time, but nevertheless I like to write about what I think are the neat highlights of the discussions and document them here for future reference. Also a big thanks to Gifford Cheung & Igor Rafael de Sousa for writing and collating notes on the Toolsmiths Github. You can also join the Toolsmiths Discord.
And last but not least a big ‘Thank you!’ for everyone that attended the USD Roundtables at GDC 2024. I sincerely appreciate everyone who shared their own stories of both joy and woe as we all strive to create better tools & workflows for everyone.
Subscribe below to get updates when a new post is published.
A photo of the board after the roundtable ended