Support OpenUSD

[Victor239]

Describe the project you are working on

N/A

Describe the problem or limitation you are having in your project

N/A

Describe the feature / enhancement and how it helps to overcome the problem or limitation

OpenUSD is becoming a universal standard, it makes sense to support it.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

N/A

If this enhancement will not be used often, can it be worked around with a few lines of script?

N/A

Is there a reason why this should be core and not an add-on in the asset library?

For universal out-of-the-box compatibility.

[fire]

What is your use case for using usd?

What is the problem or limitation you are having in your project?

Describe how to implement usd for your proposal?

It cannot be worked around with a few million lines of c++ code.

It will probably be a gdextension in the asset library.

[fire]

For future reference https://github.com/fynv/usd2glb appears to be a usd converter using https://github.com/syoyo/tinyusdz

[expenses]

Hey guys, I've been playing about with USD a bunch recently and have been looking into using Godot for a personal project. USD is a huge project and it's pretty hard to explain what it is and what it's useful, especially for gamedev.

One way that I'd describe it is that it's a very powerful file format & API for 3d scenes. It's important I think to differentiate 3d models vs 3d scenes here. USD is at it's best when it's instancing a whole bunch of 3d models around and while you can store 3d models as USD files, you can also use plugins that convert from glTF (see guc) or FBX (see usdFBX) into USD.

Having a scene format that's not tied to a specific DCC (Digital Content Creation program, e.g. blender with .blend) or game engine (Godot, Unreal, etc.) means that you can switch back and forth between programs at will and use the best of all worlds.

I've been playing around with the aforementioned guc plugin with usdview and have come up with a simple example of what USD can do:

#usda 1.0

# Define a prototype prim that references in a full glTF scene.
def "shroom_prototypes" (
    references = @projects/world/object_sources/shrooms.glb@
) {
    # Mark it as invisible so that it doesn't get rendered
    token visibility = "invisible"
}

# Define a shroom prim
def "shroom_1" (
    # Reference in a specific mushroom from the glTF scene
    references = </shroom_prototypes/Scenes/Scene/flat_top>
    # Mark it as instanceable so that various optimisations can
    # be applied.
    instanceable = true
) {
    # Set a translation for the shroom
    float3 xformOp:translate = (0,0,5)
    token[] xformOpOrder = ["xformOp:translate"]
}

# Same as above but with a different translation.
def "shroom_2" (
    instanceable = true
    references = </shroom_prototypes/Scenes/Scene/flat_top>
) {
    float3 xformOp:translate = (5,0,0)
    token[] xformOpOrder = ["xformOp:translate"]
}

Here's how this scene displays in usdview:

If we select Vis Only on shroom_prototypes we can see the original glTF scene:

I think a good first step for USD support would be to allow for this sort of simple glTF + USD scenes. I might see what I can cook up using the USD python bindings, but no guarantees.

TL;DR, I have a bunch of DOs and DON'Ts for developers interested in USD:

• DO: Join the https://www.aswf.io/'s slack and join the #wg-games-usd channel!
• DO: Investigate the possibilities of combining USD with other file formats (mainly glTF)
• DO: Try out a bunch of the USD python tutorials.
• DON'T: Get too hung up on the massive list of terms and concepts on the USD website. Remedy's Book of USD is much better at explaining things to begin with.
• DON'T: Hyperfocus on trying to write an highly capable and flexible importer for USD meshes. Meshes have a whole bunch of complicated elements, such as the possibility to contain non-triangulated geometry.
• DON'T: Hyperfocus on USD material stuff, like the UsdPreviewSurface spec. MaterialX is a better way to do materials in a cross-DCC way but don't worry too much about that either!

[RichardEllicott]

here's an example of a feature that is an absolute workflow nightmare in Godot, i think the asset workflow is probabally our biggest weakness personally

gLTF2.0 that i currently use seems to be the best, you can use it automaticly (place blender files in project and set blender as an external app to convert them)... it has reasonable material support thank god for this

no instancing! so if you make a building with 20x window instances, as you do it's most logical.... when you import to Godot it becomes 20 meshes... it's a nightmare.... so Godot has no understanding at all these are the same windows

also the lights are just garbage, they never match at all, i'm almost resigned to that one the lighting might be impossible to really look the same but it doesn't feel like it even bothers at the moment

so USD would be amazing if Blender and Godot could exchange information this way... clearly that Blender/Godot hybrid format is going nowhere, and that would have been Blender exclusive anyway .... that said i know it might not be exactly that simple, but would not even partial support be acceptible? does anyone really expect Godot to fully support Pixars screen description format or wouldn't it be more like we can benefit from this open standard because, finally, everyone agrees on something (NVidia are going all in with the Nucleus platform, i see other 3D packages seeing it as a good survival strategy)

so anyway i second this if possible, if it solved these problems

[RichardEllicott]

"You can use the .blend approach for now for usd support" >> i understand this uses the .blend method uses gltf2.0 under the hood

i think that's what you mean by "godot's blender support", your tool is a USD import? does it support anything to do with the instances in blender or is that impossible?

i guess i can sort of live with the bad lights (but i think a lot of people wouldn't mind that looking the same as in eevee), what i wanted to achieve is more linking, so a Godot file has references to scenes, a Blender file has references to instances, some of these instances even i put them in different files to control Godot's automatic import

since USD is a scene descriptor format, i assumed it must have instances... maybe it's not even possible Godot could import this anyway based on your experience writing this USD importer?

i do understand real bad reasons for USD, might be: "it was designed for raytracing? maybe it'd never look the same anyway" ... "it wasn't designed for games"... gLTF2.0 at least was designed with 3D PRB assets in mind

[fire]

The main problem is the main feature of keeping the openusd references intact by using the usd renderer is probably something that can't be kept in Godot Engine. Blender also doesn't keep the openusd references.

It means we probably need to import the openusd hydra renderer as is or dynamically translate the data at runtime.. without dropping frames.

[RichardEllicott]

i don't think anyone has any intention here of supporting the renderer... i belive it's the OpenUSD format itself.... it's used by different renderers

it's a scene description format, the idea was that it might be a better format to go from Blender (or any other OpenUSD exporting program) to Godot (than gLTF2.0, more of an asset format than scene format).... and not complete support of OpenUSD i imagine this wouldn't even be possible, surely some things a renderer can do cannot translate to a game engine

it's there being as it's for rendering which counts against it, but it's that it might be a standard adpoted by the 3D programs and therefore send more standard info accross.... what i think of are instances and lights... ones that match a standard. I prob need to learn more like can EEVEE load a scene from OpenUSD and does it look at good/close etc...... maybe it just only is worth it for CGI scenes

in the meantime anyway i'm still glad our gLTF support is pretty good, materials and all

[fire]

There are some concerns from the community about "it wasn't designed for games", like the openusd PBR model isn't designed for realtime, but it'll be degraded to fit I think.

[meshula]

I'm personally committed to making USD work well for games, but it's still early days. The OpenUSD PBR model is actually pretty much the same as the Unreal PBR model, and like the Unreal one, you can gracefully degrade it by eliminating terms that don't make sense for your application. I'm not making an argument here one way or the other, just providing a little information.

[fire]

I have taken https://github.com/V-Sekai/USD-Fileformat-plugins and built a 1.6 gigabyte package for python 3.10 (windows / linux). It can convert some openusd to gltf. I believe blend shapes don't currently convert.

[johnyc90]

Just adding my two cents, here. Hope I'm not late to this discussion.

USD and gltf are formats that solves very different issues.

gltf excels at handling 3d meshes for game development. Is lightweight and fast to process. It has it's limitations when dealing with complex scenes or different kinds of objects, as others pointed out, but that's kind of the point. It's a 3d model format.

USD is a scene descriptor. It packages a whole bunch of other information along with what's exported, along with potential custom data that can be tagged along.

USD is a very flexible format, whose main use cases steer away from just allowing the artist to have a faithful representation of the scene with its lights and instances and what not, and pave the ground for teams to build complex pipelines with external tools.

IMHO the advantage of having USD support comes especially from having both an importer and an exporter. This allows, for instance, technical artists to have the ability to interact with a Godot scene with external tools such as Houdini or blender geometry nodes, populate the scene with other stuff in a way that Godot wasn't made to do (and arguably shouldn't), and bring it back to Godot, without the hassle for you Godot devs to support all of those funky pipelines natively.