Importing USDs with referenced MTLX files does not work when using UDIMs

Development Rendering
, ,
1

The importer correctly brings in the meshes and UVs, and a UDIM material is created, but it fails to read and import the textures. We tested the texture path syntax using both texture.1001.jpg and texture.<UDIM>.jpg, but neither worked. We also tested with embedded MTLX files, but the result was the same.

We’ve attached both separated and embedded USD test files.

These test USDs work correctly in NVIDIA Omniverse.

2

Steps to Reproduce

  1. Enable Virtual textures in the project
  2. In USD Stage Editor window open either `USD_MTLX_SEPARATE.usda` or `USD_MTLX_UDIM_EMBEDDED.usda`
  3. In USD Stage Editor window change `Render context` to `mtlx`
  4. In USD Stage Editor window `Actions` hit `Import…`
  5. Materials are created but we are missing textures
  6. In the case we are importing separated the material instance is not referencing the correct parent
  7. In the case we are importing embedded the master material is missing completely
3

Hi Josef,

Unfortunately, this is a limitation of the MaterialX importer itself; it does not support UDIM. This feature request will be added to Jira but there’s no ETA when this will be added.

As a side note, the correct syntax is to use .1001 not .<UDIM> for the UDIM detection.

Thanks,

Anousack

4

Hello Anousack,

Thank you for your reply.

I would like to bring to your attention that the correct syntax for USDs is <UDIM>, as well as for MTLX.

If you set the syntax for the Unreal Engine importer to be .1001, then USDs that are compatible with Houdini, Nvidia Omniverse and other softwares will not be compatible with Unreal Engine.

Please find here the documentation for OpenUSD.

https://openusd.org/23\.05/api/usd\_mtlx\_page\_front.html

Thank you,

Vladimir

5

Hi Vladimir,

Thanks for the info. I’ll add this to the Jira so that it detects the proper token.

Anousack

6

Thank you Anousack!

7

For your information, a change went in ue5-main last week for the support of UDIM in MaterialX so it will be released as part of UE 5.7. You can find it on github: https://github.com/EpicGames/UnrealEngine/commit/935fe5c883b5a6861131bda925ffa21154447d67\. MaterialX embedded in USD is supported only in Interchange USD, but the USDImporter should support it through the external MaterialX file (also supported in Interchange USD). Note that this version of UE uses MaterialX 1.39.3. Your example used MaterialX 1.38 so it had to be modified a bit to pass the validation in 1.39.3.

8

Hello,

Thank you for letting us know - it is important for us for the USD Stage Importer to be able to work with embedded MTLX. Hopefully in the near future you will support that.

9

Unfortunately, there’s no plan for the USD Importer to support embedded mtlx, only external mtlx. Future USD development focuses on Interchange where it does support both external and embedded mtlx.

10

I think that might undermine the purpose of having a well-functioning USD Stage Editor.

From what I’ve seen, the Interchange doesn’t seem to support variants yet, nor does it allow for keeping a USD “live.”

Keeping the USD live gives you insight into its different purposes and allows you to work with multiple payloads or with just certain payloads.

With the Interchange, you’re forced to re-import repeatedly just to understand the USD you’re working with. Yes, there is the “Preview” but that is not enough.

The USD Stage Editor offers many advantages over the Interchange. However, its lack of support for embedded MaterialX, something most other can DCCs handle, is a major drawback. We’re required to generate extra .mtlx files when building USDs to make them compatible. Most client-provided or purchased USDs don’t reference external .mtlx files; instead, they embed them directly and often rely on variants as well. For example, variants can be used for, well, different material variants, for mesh variants, and in the future even for simulation variants, such as a tree swaying slowly or fast.

All I am trying to say is that at the moment, neither the USD Stage Editor (Importer) nor the Interchange can be used reliably, as each have their quirks. I am aware that they are not production ready, but it is important for each of these two importers to be heading in the right direction. We would like to request, if possible, to continue with the USD Stage Editor and at least implement embedded MTLX support for it.

I am open to discuss this further with you if you would like and go in depth in this topic.

Thank you,

Vladimir

11

Hi Vladimir,

Thanks for your feedback.

We agree that there is value in both the “pure translation” workflow where USD scene data is converted into Unreal assets, and the “live stage” workflow where a persistent connection is maintained with an open USD stage. At the moment, our development effort is focused on the former, where we are migrating to the Interchange framework to make the import process more robust and customizable.

The UsdStageActor in its current form is backed by essentially just an import behind the scenes, and we think that that is the source of many of the performance and scalability problems we’ve heard in feedback from users. We’ve been discussing whether we could move it off of the “legacy” import functionality and onto the new Interchange-based support when it is ready, but that is still a little ways off. We’re also considering whether there are other ways we could provide the same features offered by UsdStageActor in a way that does not require a full import. In either case, our eventual goal is to process all USD import through Interchange and ultimately deprecate the legacy import, but we don’t have a timeline for that that we can share right now.

At the moment though, that does mean that UsdStageActor continues to use the non-Interchange “legacy” import functionality, which as Anousack mentioned only supports MaterialX when it is referenced into a USD composition and not when it is encoded directly in USD as UsdShade.

Thanks for letting us know that MaterialX-as-UsdShade is important to you when working with UsdStageActors though. We’ll discuss this internally and see whether it would be feasible to port that feature back from the Interchange-based import.

-Matt

12

Hello Matt,

Thank you for your thorough reply and for the information provided.

As a final few questions in this thread…

1: In the future, do you plan to introduce variant support for the Interchange? If so, do you have any time frame for that then?

2: What is your current support with NodeGraphs?

When importing .MTLX with the Interchange, NodeGraphs are read correctly, flattened and rebuilt.

When importing .USDA with the Interchange, we get an error that NodeGraphs are not supported.

This needs more testing from us, but what is your current progress on this?

I can provide an USD that has NodeGraph primitives in it as an example.

3: How do you see USD Procedurals being implemented in the future? I did not have much luck importing any USD with Procedurals yet, as they are only used during render time. For example, how do you see Houdini Procedurals working with Unreal Engine? They are render agnostic and can be saved to USD.

I am aware that those are all hard topics but as we are fully switching to an USD Pipeline, these are important to us.

Thank you,

Vladimir

13

Hi Vladimir,

Glad that information was helpful. Here are some thoughts on the questions you asked:

  1. Support for changing variant set selections is actually a feature of the UsdStageActor and not inherently supported by import. Although variant sets allow choosing between multiple possible variants, the selection of which variant is active is actually authored in the USD, so when the stage is composed only one variant is active. Neither the legacy import nor the Interchange-based import interfere with your variant selections at all and instead simply import from the stage as authored. What is happening with the UsdStageActor when you change variant selections is that behind the scenes it’s doing a re-import of that section of hierarchy after having authored a different opinion. Outside of the UsdStageActor, the only way to import all possible combinations of variant selections from a given USD scene is to import that scene multiple times with the selections you want authored, and that’s true of both the legacy import and the Interchange-based import.
  2. We are indeed aware of the issue you mention with MaterialX-as-UsdShade when you have NodeGraph prims authored in your USD scene. We have an issue for it open internally and will be looking into it soon.
  3. We do not currently have any plans to support the execution of procedurals that might be present in your USD scene. While Hydra typically takes care of that execution in other DCCs, we do not make use of Hydra in Unreal Engine. UE works fundamentally differently from many of those other DCCs and is more an ongoing simulation rather than simply producing a render, so it’s somewhat unclear when is the appropriate time for a procedural to be executed (or re-executed), and we’re also not able to make any real-time guarantees around performance when the execution of a procedural could be invoked at unpredictable times and/or run for an unknown amount of time. We have discussed it internally at some length and do return to it periodically, so while we’ve not fully dismissed the possibility of doing something with them in the future, it’s not currently an area that we’re focusing on. As you mention, there are some pretty hard open problems around what their use would look like in UE, and we would need to ensure that users have a good experience working with them in engine. If you’re working with Houdini, your best bet is likely to have Houdini execute the procedurals and then shuttle the data across to UE via Houdini Engine or some other mechanism.

Hope that helps!

-Matt

14

Hello Matt,

Thank you for the very helpful information and for your time.

  1. I see, it makes sense.
  2. We are looking forward to a fix in the future for this issue.
  3. This is the hardest topic - indeed, it’s implementation poses a problem and it’s not something that seems compatible with the Unreal Engine workflow - we have already thought of your suggestion; we execute / *bake* the procedurals and then we either re-export the USD or bring the needed data in via Houdini Engine. It seems like the best compromise to deal with this.

Thanks for the sustained support you and your team have given us.

There will likely be more issues / questions coming as we develop our USD Pipeline, but hopefully we will be able to fix those together if need be.

Thanks,

Vladimir

15

Hi Vladimir,

That sounds great, and thanks again for your feedback.

Feel free to post a new report for anything you run up against in the future.

-Matt