Feedback needed on exporting materials

[scottrenaud]

Hey everyone,

We’d like your feedback on some material export designs.

Material scope generation update

Firstly, we'd like to propose a simplification to our material scope generation rules that can result in inconsistent/hard to predict output, where multiple scopes get generated in different places and in cases none, which doesn't quite fit or support our idea of a clean/organized asset structure.

The new rules would be:

• The mtl scope should be created under the default prim (unless mtl is the default prim)
• When there is no default prim, the mtl scope should be at the scene root

Current logic (expand to view)

• if there’s a single root xform then create mtl scope under it and place ALL materials under it
• else then
• if there’s an xform that contains 1 or more prims that have a material, and that material isn’t used elsewhere, then create mtl scope under that xform
• if there’s 1 or more xforms that contain 1 or more prims that share a material, and if there’s no root xform then place those materials in the root not under an mtl scope
• if there’s 1 or more meshes, that aren’t contained in an xform, then place those materials in the root not under an mtl scope
• if there’s no mesh to be exported then
  • if there’s a single root xform then create mtl scope
  • else place all materials in the root not under an mtl scope

The following images show a few examples of before/after:

Exporting materials only

Second, we want to allow artists to export/duplicate materials to USD without having to also export/duplicate meshes.
This would also come with a few improvements:

• New "Materials" checkbox to indicate intent in a clearer way
• Ability to select "mtl" scope as default prim when meshes are disabled
• Ability to export assigned materials only, to export what's relevant (new checkbox in Materials section)
• Ability to exclude empty transforms from exports, to keep exports clean (new checkbox in Advanced section)
  • After filtering types of data depending on selection and options, this logic would check for transforms that are empty or only contain transforms as children and include/exclude them from export.

Here's some examples:

Exporting all materials

export_all_materials.mp4

Exporting selected materials

export_selected_materials.mp4

Duplicate selected materials to the stage

duplicate_selected_mtls_to_stage.mp4

Exporting assigned materials only

export_assigned_materials_only.mp4

Include/exclude empty transforms

We'd like to know:

• Do you have any questions or concerns regarding the proposed rules for scope generation?
• Will this impact your pipeline?
• Do you have any questions or concerns?
• Is there anything missing or you would do differently?

Thanks!

Scott

[email protected]

[sharktacos]

I wonder if, in addition to the mtl scope, the meshes should also be under a geo scope? As described here:
https://github.com/usd-wg/assets/blob/main/docs/asset-structure-guidelines.md

USDscene/
    geo/   (scope)
         group1/    (xform)
                mesh1
         group2/    (xform)
                mesh2
                mesh3
         mesh4
    mtl/    (scope)
         material1
         material2
         material3

[wallworm]

Definitely, we want to improve the exporter to have a better default structure (including geo). But for the moment, our focus is on the materials since the mtl scope is already part of the exporter logic but its currently inconsistent in where the scope(s) end up as well as the materials. Our main concern right now is that the change we are looking at isn't going to cause any issues with existing pipelines.

[sharktacos]

That’s reasonable. Well, from my perspective the proposed changes to the materials scope are welcome improvements. Hopefully we’ll get others perceptive here as well!

[sharktacos]

Currently assigning a new shader adds a new mtl scope parallel to the assembly root.

So for example, say you have the Pixar Kitchen USD loaded and you want to assign a material to a component, say the table. I would wish that it would put the material under the existing mtl scope for the table, but it instead makes a new mtl scope under the main kitchen xform.

Will this behavior change in the new proposed behavior? Hope so.

Let me add that this is not relevant for exporting a component (no issues there), but rather for the case where several components are assembled in a scene and one wants to make an override in a sublayer to a material binding, assigning a new material.

[daviddeacon]

When exporting materials only, would there be a way to export the materials plus material assignments?

I'm thinking of an example where geo is exported to a Usd file and the materials are exported to a separate Usd file and these files are sub layered together to complete the asset.

[scottrenaud]

Hey @daviddeacon, that's not part of this design but I'll discuss it with the team.
In your asset structure would you prefer to have material assignments to be in their own sublayer or you'd see them being part of the material layer?

[daviddeacon]

Having the freedom to have them separate is always nice to have as an option.

Our current workflow is create assets using native Maya geo and shade them also using traditional native Maya shader nodes, and have a custom asset exporter tool that uses the cmds.mayaUSDExport command, but currently we need to publish new geo for a shading update. It would be great to be able to just export shaders and material assignment to sublayer over a geo only layer.

[dveight]

I'd like the same ability that @daviddeacon mentions. Being able to export a layer with materials and bindings is ideal for our pipeline where we cache via mayaUSDExport and to mulitple layers.

[sharktacos]

Another option is to export the materials separately, and have a "look" file that contains references to these materials along with their bindings as an over to the geo. An example of this is the Open Chess set. So you would have: An asset file that payloads in a payload file. The Payload file contains two layers: the geo file and the look file. The geo file contains the geo, and the look file contains references to the material files and the bindings as described above.