Notes of the OpenUSD Roundtables at GDC 2025
This year we had 2 OpenUSD roundtables. 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. Day 1 was focused on OpenUSD workflows, and day 2 was focused on OpenUSD tech.
The topics discussed at day 1 were:
What material system do folks use, and why?
Variants, why do you use them, what do you do with them, and what are the pros & cons?
Live sync vs Hot reload, what’s the good and the bad?
Who is using USD? For what, and why?
Realtime & offline rendering: Is anyone using both?
What is stopping you from starting with USD?
For those who have never attended a roundtable at the Game Developers Conference (GDC): This is a room filled with mostly game developers, from both big studios and indie studios, as well as non-game developers from manufacturers, TV, movies, third party software developers, 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, not directly from me, and written down after the fact from memory and shorthand notes, so always take it with a grain of salt, as your own situation may vary.
1. What material system do folks use, and why?
We did a poll by show of hands, and MaterialX was the one mostly used, followed by MDL. PreviewSurface is technically used by everyone as it’s part of USD, but it wasn’t in active use by folks for its functionality. Conversion was brought up as an issue between the various material formats, and that it's not great yet. This was a continual refrain in the roundtable: A lot of 'Not Yet'. Features can function ok, and it can be technically possible to do something, but it is very tough to do with the speed and iteration necessary for game development productions.
2. Variants, why do you use them, what do you do with them, and what are the pros & cons?
Last year when this topic came up, the answer was: Do not use them, as they are so difficult to work with. They are hard to build, hard to maintain, and hard to iterate.
This year, it was a little different. There was some very cautious discussion that variants are powerful and useful, but to be careful with them. Variants can easily break, and are hard to maintain, but they can also make workflows much easier when having to change out assets, materials, or other primvars.
We ended up equating it with nuclear power: It is super powerful if used correctly, but requires a lot of setup and knowledge to make it work correctly. And, if someone does something wrong, you now have a lot of contamination to clean up. Goodluck finding out where the issue is!
A big part of this discussion was the lack of tooling that makes it easy to both work with and adjust variants. It is possible to make them and edit them, but again the refrain of: “Not Yet.”, in that it is possible, but difficult to work with at the moment.
3. Live sync vs Hot reload, what’s the good and the bad?
What came out of this discussion was that instead of directly moving over the data of the USD layers/files, folks found that instead if you copy the changes you perform in one DCC and then copy those changes between the various others DCCs you have, you end up with the same identical content in each DCC without having to do a lot of live sync or hot reloading of the USD layer data itself. So they are not moving the USD data itself, but copying the changes between DCCs. Apparently that works very fast and is a really powerful workflow enhancer.
A question that came out of this, due to the enthusiasm of some AAA folks and software vendor folks: Hey that's neat and all, but what is USD? Why should I use this? Is this good for our use cases? A lot of folks mentioned the 'What is USD?' video that I put up on YouTube about 2 years ago, saying that this answers most initial questions. At the roundtable on the next day we heard a lot of folks were helped by that video.
4. Who is using USD? For what, and why?
We had a spread of folks in the room who were using USD, mostly consisting of large scale AAA game developers, some robotics folks, film/TV/VFX, and even theme park entertainment. Some reasons brought up for the use of USD by folks in the room was:
The power of referencing
Composition arcs are very powerful and allow multiple folks to work on the same content through different files. This especially helps large teams have less trouble with version control, and allows them to use the same content in various DCCs including internal engines/editors.
It’s open source
If you want to change something, you can change it. Especially companies with internally made custom engines/editors really liked that they can adjust what they need, when they need it, without having to ask anyone for permission or an expensive SDK.
It solves particular problems in their pipelines
Especially in AAA games the solutions made internally are often entirely unique for their own situations. This was hard to quantify exactly by the folks in the room. It really depends on what problems you are having in your pipeline that you need solved. For example, it may be that moving animation data between two DCCs is very time intensive workflow for your in-house users, and OpenUSD happens to make that loop much easier once you have a schema implemented that retains the data you need between them. For another studio it was having digital twins for a robotics factory, and OpenUSD happened to make that incredibly performant and much easier than other SDKs. So the correct answer here is, as per usual: It depends.
But the main thing I took from the answers was: Not many folks are using OpenUSD yet, and even those who are, are doing it nearly silently. We heard from some big studios that are using OpenUSD, but the only one being incredibly public about it is Remedy. Other studios are trying it out, looking into it, or even have half of all their art content is already transferred to USD files, but they are not shouting it off the rooftops. It is a slow and gradual process as they figure things out, work with it, and make adjustments. The majority of the room was not using USD, and instead wondering why everyone else is using it, what for, and if they should use it too. There is interest, and good discussions, but many folks are still taking caution. As we say in Dutch: They are looking the cat out of the tree.
5. Realtime & offline rendering: Is anyone using both?
Folks mention they use USD to teach workflows for VFX in university so they teach a bit of both, and its use for robotics where you both need to real-time show how a factory works, and also have to offline render to make it look beautiful. In videogames there wasn’t a big push to use both, but I guess there could be depending on marketing material needing high-definition renders of in-game content? It’s a possibility, it may just not be a big focus yet.
Again: “Not Yet.”
6. What is stopping you from starting with USD?
Because they do not know what it is. What is it supposed to do? How would we use it for our projects? There are a lot of neat words being thrown around, but unless we can prove that it resolves something, why would we start using it? This topic also made a comeback in day 2, and I think it got a more satisfying answer there.
What is also stopping folks from using USD was the lack of good tooling. It was hard to get started, and hard to edit, as we also saw in the variant discussion. Houdini’s Solaris was brought up as a great location to edit USD in, but other DCCs were not quite up to a degree where editing large complex USD scenes, or small reference heavy USD scenes, was comfortable.
Again: “Not Yet.”, but it is slowly but surely getting there. People were more positive then last year.
Below is the whiteboard for Day 1, and below that are the notes for Day 2:
The board of day 1
Day 2
The topics discussed at day 2 were:
Who has an actual pipeline of USD assets for animation?
What is the business case for convincing your studio to use USD, and how do you deal with conflict/compatibility?
Does anyone roll their own serialization?
How do you convince engineers, and what are good OpenUSD resources?
USD for Unreal: Who uses it, and is it good?
Is there a vanilla USD implementation that I can use?
1. Who has an actual pipeline of USD assets for animation?
For example, does someone have a Maya to Motionbuilder pipeline, one with skeletons and control rigs that transfer correctly between DCCs?
The answer from the room was: Not really, or at least not for that specific case. Folks do have an actual pipeline of assets for USD, but they are very specific to their own use cases and workflow. Not that it is impossible to move animation data, but you would have to look at how your setup works, make schemas for that, or use existing ones, and then make that transfer easy.
It is possible, it’s just hard. OpenUSD is hard to use at the moment, it is difficult to get into, it is difficult to get through the initial barrier of confusion over terminology, and to find out how it can help you. The folks who have had the time and energy to push through that have come out happy on the other side, though even for them there is always more to learn and use. In my experience even folks who have used USD for 15+ years do not know everything about it. The OpenUSD SDK is just that huge.
2. What is the business case for convincing your studio to use USD, and how do you deal with conflict/compatibility?
OpenUSD supporting scene graph workflows was an important item for convincing studios to use it, and to more easily deal with conflicts. In the case of OpenUSD, a giant scene graph can be built out of hundreds of layers, and each layer can be separately opened, saved, and versioned. This makes larger content structures easier to work with, and so that helps convince business folks.
Another thing was having easier analytics for content. For example being able to pull from the USD data how much content is used, and where, to give you a clear idea about what content you have. This then also helped with debugging that content.
Folks also mentioned that USD is scary, as we have also seen from many answers before: It is powerful, but also difficult to understand and hard to use. A way to get around this issue and still push for USD is what we ended up calling the “Trojan Horse” approach: You solve one small problem in a good way with USD, like for example a 10 minute task becomes a 2 second task due to USD, and then the artists & designers who are happy about that will advocate for more USD. So the idea is to get small support from the inside, and that helps convince more folks, including later on into business folks. Especially ‘parlor tricks’ that make OpenUSD look neat in some visual or workflow way were seen as helpful to get USD’s foot in the door.
There are also often engineers who say ‘I could do better’ and they figure making their own 3D file format and pipelines instead of using OpenUSD. I personally think this is due to not knowing what OpenUSD can do, and to be fair, it is really difficult to find out what it can do for you, so I cannot blame them for thinking so.
Also, another topic that came up when it came to the business case: OpenUSD is free, and some folks like using USD out of spite. FBX was mentioned as some folks feel hurt by it in the past. Sometimes FBX worked great but then if they had to adjust something very specific, or needed a particular SDK build, they suddenly had to pay money for that privilege. With USD, they were at least confident they wouldn’t suddenly get surprise costs when having to solve an imminent problem. This made the business decision for USD easier, as business folks do not like surprise costs.
One big difference in this discussion was that there were essentially two camps: One said to use USD you have to fully change your whole pipeline and really go full force into USD right away to make working with it worthwhile, while the other camp said that slowly moving into USD was good to get your feet wet and slowly learn more about it as you rebuild your tooling. Both camps were very convinced of doing it one of their ways. I think this signifies that ‘it depends’ on your situation, and that neither is wrong. Every studio, every project, every culture, every pipeline, is simply unique.
3. Does anyone roll their own USD serialization? Especially to read/load?
No. Though it was mentioned that compiling your own schemas for every single individual DCC is a pain. It’s powerful and great when it works, just time consuming and difficult to set up.
4. How do you convince engineers, and what are good OpenUSD resources?
Telling them OpenUSD has open source access and they can look at and tweak anything they like was brought up as a huge boon. Also again the Trojan Horse or Parlor Trick approach of solving a key problem or showing cool demos. When it comes to resources, things that were brought up are:
What is USD? An explanation in 10 minutes
To get a basic idea of what USD is, and how it works.
For many simple explanations and gifs that explain difficult concepts quickly.
For getting started if you are a technical person.
For a lot of reference material.
A free app for opening up USD files, and playing around with basic USD functionality such as variants.
For being part of discussions, seeing questions, and downloading free example assets. Some are public domain (CC0), which helps!
Because Houdini is as of yet the best place to edit USD in.
If you want to try building things in the omniverse ecosystem.
In 2024 Remedy did two fantastic talks about USD, one about the workflows, and one about tech.
5. USD for Unreal: Who uses it, and is it good?
Very few folks were using USD in Unreal, and those who did said it was not great yet. The workflows were rough, and Houdini’s Solaris worked much better for USD editing. But, they want to keep on trying to use Unreal, because they are used to using it already, it does do general real-time development well, and real time rendering very well.
Again, similar to day 1: “Not Yet.”
6. Is there a vanilla USD implementation that I can use?
No, there isn’t.
A few folks who had never used USD before brought this up as a big barrier. Houdini was brought up again and again as a great testbed for trying out USD in, but implementing USD into their pipeline is still very much a custom operation that depends on what they need. But how do you know what you need out of USD if you haven’t used it before? It creates a chicken & egg situation, and a vanilla USD implementation that works for basic pipeline needs such as import, export, referencing, etc, would in my opinion be good to have. Especially to build out the community more.
The whiteboard of day 2
Thank you
Last but not least a big ‘Thank you!’ for everyone that attended the USD Roundtables at GDC 2025. 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. I was great fun to host these USD roundtables for the second time this year. I hope to see you all again next year!
Subscribe below to get updates when a new post is published.