Pixar's USD, Thoughts?

An other Talk about USD.

1 Like

This thread’s a year old – anybody got a personal take on how it’s working for them?

I’m still a believer in the concept behind Universal Scene Description, but the investment required to build a pipeline around USD in the current state can still be quite large. VFX/Film productions will no doubt have an easier time adopting it as a replacement for previous Alembic based scene layout workflows.

For game devs though it is complicated. It is pretty easy to run into walls depending on what you need to represent and/or edit once assets have moved over to USD.

These challenges could be overcome if a team has the resources to dedicate devs to custom schema + translator + integration + hydra work, but pulling tech artists and engineers away from their core responsibilities to focus on this is a hurdle on its own.

Your assessment is pretty much what we also discussed internally with a sister studio … I look at the work involved, the time and resources we have, and it’s the equivalent of a project in itself.

Nvidia showing Omniverse inside Maya.
There is a lot goin on in the USD land.

Great USD Article inside.

Has someone tried the latest Maya_USD Build?
There is a lot new stuff inside.

In conversations with tech artists, the existing pipeline for FBX in Unity and Unreal Engine has been hard work and mostly works.

Learning about how FBX works and writing an importer is harder, but it’s worth the effort for alternative game engines like Godot Engine.

Making a 3d import pipeline in games work for glTF2, which is limited in scope and has like 10+ implementations, is doable. However, as of Aug 2020, the official Blender glTF2 exporter is still fixing bugs in its exporting process. For example: 1) not inheriting rotation or 2) not having animation vertices with normalized bone weights or 3) unweighted vertices in a skeletal mesh. These are still incorrect in Blender 2.83 stable LTS.

However, supporting USDZ, which supports embedding video and audio, means that you need to integrate the audio and codec spec into the implementation with the associated costs.

glTF2 has an extension mechanism. The base gltf2 specification is already useful. The number of glTF spec following implementations support this theory of being useful.

The entire USD library is a million lines of code and more https://github.com/PixarAnimationStudios/USD, not including dependencies. The gut count seems to be like close to two or three million. tinyusdz is the only one I could find implementing scene import support with no skeletal animations.

tinygltf embeds an entire JSON parser, but it’s at 400 thousand lines of code. If you have an existing game engine, writing a gltf2 exporter and importer can be 8.5 thousand lines of code.

I don’t know if implementing USDZ support is worth it for a small organization. It seems that the other projects import the USD library directly.

A mixer approach might work better where the entire level is streamed live as an application. https://github.com/ubisoft/mixer

That’s a useful perspective: LOC is not a measure of quality but definitely tells something about the long term evolution of a codebase – 3m is getting into Unreal Engine territory, which means there’s likely a lot of small-scale issue hiding in there which won’t hit everyone but will annoy a few. I’d be very interested to hear from somebody with inside knowledge how the project hit that scale, and which parts drive the complexity.