This article complements the USD Playground application, which lets Users edit a USD scene and see its content updated live in their browser.
Given Pixar’s Universal Scene Description (USD) original intent of facilitating the exchange of large scene data for production needs, it is understandable that the accompanying toolchain could also be extensive. After all, the environment in which you would be moving gigabytes of data with hundreads of references for processing depends on a pipeline built to satisfy some of the most demanding workflows in the industry.
While it stands to reason that artists and technical directors would use tools of corresponding scale to accomplish their tasks, there is still a need for “simple”, low-latency, interactive tasks. In other words, simple changes outside of desktop-bound content creation tools.
This was the motivation for attempting to run USD on the Cloud, as a microservice.
For most automation tasks, a pipeline relies on a typical run-of-the-mill infrastructure where run-of-the mill components are used (queues, databases, storage, render farms, etc.). While this works well for scheduling and balancing heaving infrastructure loads & costs over time, this implies high latency between performing an action and obtaining the final result.
To render final frames or assembling scene assets for an artist to work on, latency may be less of an issue… but there are other use cases where this infrastructure delay can cause frustration:
With productions moving to the Cloud, and competition in that space becoming more aggressive with reduced costs and diversified offerings, there is an opportunity to run USD as a microservice. This means executing tasks away from a few scattered datacenters and near Users, in order to further reduce latency.
Yes! By jumping through a few hoops, it is possible to run USD natively in a Cloud function, for multiple providers. The USD Playground application easily runs in a 1024MB Lambda function with lots of headroom to spare – although it arguably does little processing other than geometry transformations at the moment.
There are some constraints to this particular workflow. These are linked to the very nature of this solution, which favors low latency over anything else. This means removing all components which cause latency in traditional pipelines (networking, storage, database queries, etc).
In other words:
64-bit WebAssembly, hopefully.
The original intent of this project was to build USD for WebAssembly, in order to run USD tools directly in User’s browser for minimal latency and the inherent privacy and security features it offers. Since WebAssembly is still limited to 32-bit applications and USD requires a 64-bit compiler, this was unfortunately a no-go.
For the USD Playground itself, additional features can still be added to provide a better experience, and to allow the community to learn more about the format. Some of these include: