First steps with Universal Scene Description

This article was updated on 2019-07-26.

Universal Scene Description (USD) is a file format created by Pixar. To create, manipulate, and read those files, they have also released their C++ library under the MIT Open Source license. Since the work on Toy Story started, Pixar have been trying to solve the challenge of having large teams of people working on a consistent set of digital files, with the aim of creating a feature film. This work culminated in USD, and with all the filmmaking experience of Pixar poured into an Open Source library it’s no wonder people want to see USD support in Blender as well.

In the past month I have been working on adding a prototype USD exporter to Blender. In this blog post I will explain what has happened so far and what steps are needed to move forward from here.

What happened so far

The USD library is rather pleasant to work with, so creating a simple exporter went pretty smoothly. The current work is loosely based on the Alembic exporter, with of course some improvements that’ll circle back to Alembic at some point. What we can do so far is:

• Export a single frame or all frames in the scene,
• write to a single USDA (ASCII as in the screenshot above) or USDC (a more efficient binary format) file,
• export static and animated meshes with modifiers applied, including UV coordinates and edge creases,
• write simple materials based on the viewport settings,
• assign materials to subsets of the geometry (I think this works, but the Hydra viewport doesn’t support this yet, so I can’t visually verify),
• export hair curves (just the parent strands, and not coloured yet),
• export lamps (except spot lights, which USD doesn’t seem to support),
• choose between Render of Viewport settings (for Simplify, modifier settings, etc.) to determine what ends up in the USD file.

What is not there yet

The way the exporter works now is rather limited, for various reasons. To start, writing an entire scene to a single USD file is not the way to go. This is evident when looking at the USD example files from Pixar, where every object is split up into three files and then referenced from the set definition file to form the stage on which characters can be animated. The Kitchen Set consists of no less than 230 files.

Splitting up the scene into smaller files allows more efficient loading, writing, and modifying a scene, and in general makes it possible to work together without stepping on each others’ toes. However, how to exactly break up a Blend file into small USD files, and subsequently how to tie those files back into a USD file that shows the same as you had in Blender, that’s still an open question. This is likely to be studio-dependent as well, so requires flexibility from Blender’s side.

Then there is the concept of instancing. It is possible, both in Blender and USD, to have many copies of the same object without bogging down your computer too much. For Spring a shot with >10,000 individual objects is quite common; many of those are instances of the same pebble, rock, twig, or leaf and can be efficiently stored in memory. However, when writing those to USD with the current exporter in Blender, they are all written as individual objects. I have added some experimental code for creating references, but to do this efficiently the previous issue — what to store in which file — should probably be addressed first.

Finally there are all the features USD supports that we simply haven’t gotten around to building into Blender yet. To mention a few:

• Richer material support: currently we only store diffuse colour, metalness, and roughness from the viewport settings of the material.
• Authoring variants: the concept of variants, for example a flawless and a chipped version of the same tea cup, is deeply engrained in USD, and “supporting USD” should take this into account.
• Skeletal animation: currently we only write the evaluated, deformed mesh. This is for a good reason, as it ensures that the animation you see in Blender is what is actually written to USD. However, writing skeletal animation would open up interesting avenues of collaboration, for example for authoring game animations.
• Light emission from mesh surfaces,
• Ways to influence USD-specific properties; for example, lamps in USD have a colour temperature setting that Blender does not have.
• Importing USD files, with everything that comes with it,
• … and many more

Conclusion

USD support in Blender is still very much Work In Progress. Proper support for an USD-based workflow takes a lot of effort, UX, UI, and software design, and I’m guessing a few developers can easily enjoy themselves for a full year on this. If you’re interested to give it a try, check out the sybren-usd branch (you’ll have to build Blender yourself though). If you have any knowledge or experience with USD, please contact me at [email protected] or the blender-coders chat channel as I would love to pick your brain.

Update 2019-07-26

I’m blown away by all the positive response. Thanks everyone who sent me tips and suggestions for improvements. Since posting this article the following has been improved in my branch:

• Added exporting of lights (the blog post was already updated for this, but I wanted to mention it explicitly).
• Removed the “uv_” prefix from the names of the exported UV maps. This allows you to use special naming if you’re using other software that expects it (apparently Maya handles the name “st” in some special way).
• Added exporting of mesh normals. This includes marking the exported mesh as polygonal mesh instead of Catmull-Clark subdivision surface, which is necessary to properly show things like custom normals.
• Tested the merge of the MantaFlow branch and my USD branch, and it worked flawlessly.
• Added exporting of mesh vertex velocities for fluid simulations. This is now only done for Blender’s current fluid simulation, and not for MantaFlow; I don’t want to have any tight coupling between the two branches.

You can try some of the USD files we created with Blender and see how they work for you. Over time I’ll upload some more files there. Please check the timestamp of the file against the changes in my sybren-usd branch; you could be looking at a USD file that has some irks that have already been addressed in Blender.