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.
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.
… 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.
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.
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.
I’m sold on USD by this point. Even with the current limited state of the Maya integration I’ve found it has the potential to solve countless pipeline problems in game development too. You can just do things natively with USD that otherwise require copious amounts of coding duct tape.
I suppose the biggest catch right now is to make the most of USD and its collaborative qualities you really need to dive into the API. Don’t expect your Maya scenes to perfectly translate either.
I’m still trying to conceptualize how USD works in a pipeline. It sounds like a USD can be a mega-file where many different people from different teams modifies it. How does that work with source control? How do people not overwrite changes? Can only one person can modify at a time? I understand USD can be nested a reference other files, but someone still has to add the referenced files to the “master USD” right? I’m still going thru the slides so maybe that’s explained later…
Think instead of terms of Maya’s referencing system, but more so.
Basically you can have a master scene file that references in Character A, B, and C.
If folks make a change to A, B, or C, those changes get reflected in the master scene once you’ve updated your local copy.
But lets say you’ve swapped out one of the textures on Character A. Well even if someone changes the original texture, your change will persist in your scene file.
And if someone goes and references your scene, into another larger scene, they’ll see your edits. Which they could then locally override in their scene, and so on.
@bob.w thanks a lot for that example! It helps me understand how it would work in a pipeline. I watched a video on how Houdini’s new “Solaris” context will make use of USD. I figure I’ll learn through trial and error once that’s available later this year.