Pixar's USD, Thoughts?


#1

USD was a hot topic at SIGGRAPH.

I have heard many people saying their apps would embrace it, many people saying it will replace FBX, etc…

I don’t know, from a cursory look, it seems to be USD is a file format that tells you what versions of what models are in what shots, with what exposed params overridden, using what caches on disk.

It looks like it shipped with a single deformer; the alembic file format plugin.

Let’s say you wanted to store skinned meshes and blendshapes, you would then write a file format plugin, and your own file format, and it could be loaded for all apps that have USD support?

Is that the power of this? Instead of writing a Max, Maya, Lightwave, Modo, Blender, Mario Paint custom plugin, I can just write it once?

Then there’s the whole referenced scene description vs how people treat FBX as a single asset format many times.

Anyway, would love to hear thoughts…


#2

I think you’ve basically got it. Having taken a cursory glance, they don’t support rigging ( “too many vendors with different standards”), so it really only supports models, shaders, and scene setup stuff for lighting. But this doesn’t mean you couldn’t bake down animation, kill the rig, then send it to many different types of renderers that support the load for this file format.

I think if you had this combined with Material X, you’d have a very powerful file transfer format that would allow your artists to work in 3d package of choice and have clean transfer of data across those packages. If we could better solve the rigging problem, ie: I could build a custom rig that allows animators the control they want on any creature/humanoid/prop that works in all 3d packages, then we as artists win because it just becomes which program we prefer to work in.


#3

… allow your artists to work in 3d package of choice and have clean transfer of data across those packages

Scary sentence.

A good 3d format isn’t that hard - what’s hard is mapping between different program domains. If FBX was just a reference format it would be way better, but the effort to support seamless interop between packages with incompatible feature sets is what makes it simultaneously wonky and cumbersome. At least nowadays you could sort of manage this for PBR materials but the rigging domains are so different that I can’t imagine this reaching a useful state fast. A reference format is a great idea; an interchange format is going to run into the same structural problems that make FBX so wonky and Collada such a write-off.


#4

I agree about the reference format, but Pixar is looking to solve the interchange format with this. Having used FBX across multiple programs, I really don’t think it’s been used correctly. Modo, Zbrush, Maya, Max all have very different settings when using FBX and where they differ it’s because they make assumptions about the standard use. I get it though, Zbrush doesn’t have the concept of centimeters or meters as a measurement tool, so you “can’t support it”. (Sizing interop between Zbrush and Max as a domain for example…) But to me, if you’re going to add the support for FBX or USD, then you need to follow the standard completely. A reference format would have the exact problems if not implemented completely.


#5

Now two years later. Who is in a USD pipeline?

two videos for a starting point.

AL_USD

Walter


#6

They pushed out schemas on skeletons, skeletalAnimation and weight data earlier in the year.

http://graphics.pixar.com/usd/files/SkinningOM.md.html
https://graphics.pixar.com/usd/docs/api/usd_skel_page_front.html

Its basically an interchange format, with deep hooks into the composition of the final scene, with layers, overrides and referencing etc.

MaterialX is essentially the same thing, but it seems to have stronger real world bindings, Autodesk is onboard with ShaderX which essentially does automatic compile to shading engines, OSL, HLSL etc.

I can see it being the future, but it runs the risk of becoming a flavours hell, with everyone rolling there own version. It’s the trick of building a framework thats granular enough, but not so granular that you have to fork it to work with your pipeline.