MaterialX/OpenPBR issues with normal maps and metalness

Hello everyone,

We are working on a digital twin proof-of-concept for an oil & gas client. While they have not explicitly stated a target platform, they are interested in OpenUSD, open standards in general, and being forward-looking. On our side we are treating Omniverse as the rendering target with MaterialX/OpenPBR as the material system and shading model.

We are authoring USD assets from Houdini and are running into a couple of hickups that we hope can be addressed. Two specific things we are noticing:

  1. In Real-Time 2.0, MaterialX OpenPBR materials don’t render metalness correctly, while MaterialX Standard Surface does.
  2. In Real-Time 2.0, neither OpenPBR nor Standard Surface display normal maps correctly once metalness is introduced. The problem is proportional to the amount of metalness.

In path-traced mode, the results for both OpenPBR and Standard Surface match their respective Houdini Karma renders. Please see the progression of screenshots below, they showcase both problems:

This is the material network for the toruses. We have found that we need to change the signature from Float to Vector 2, otherwise Omniverse fails to load the material.

And lastly, a real-world example:

Versions:

Houdini 21.0.440 (MaterialX version 1.39.3)

Kit SDK 108.0.0

RTX 5090 (Driver 576.88)

We are hoping these issues can be sorted out and that we can move along with the current pipeline. I’d be happy to provide additional info. Thank you!

OK, thanks for letting me know. I will pass this along to the RTX developers. Just curious, but how does this look in real time 1.0? You can still enable this in kit 108 by going to preferences rendering and reenable it. Right now, I cannot give you a quick fix. It will just have to be improved for the next release.

Thanks very much for that, Richard.

In Real-Time 1.0 it just looks a little bit different.

EDIT-

To confirm that it’s not an authoring issue on our end I opened the OpenPBR shader playground scene and it appears to show the same behavior.

I am not familiar with the scene. Can you send me the link to this playground scene?

Sure thing, Richard.

https://github.com/DigitalProductionExampleLibrary/OpenPBRShaderPlayground/archive/refs/tags/v1.0.zip

EDIT-

I forgot to mention, in Omniverse it was necessary to multiply the light intensities by roughly 400 to get appropriate light levels.

Hello, are there any updates on this?

Yes, big update. We have reviewed this data in detail and confirmed that a) metalness does not work correct with Realtime 2.0, as stated and b) we are exploring some additional minor bugs to improve and add to RT2.0.

Thank you so much for bringing this to our attention. We hope to have this fixed asap and released to the public in an update.

That’s great to hear! Thank you for the update, Richard. We will keep an eye out for updated builds.

1 Like

Happy to help and I will keep an eye out.

any updates on this? thanks

I wish it works that fast :-). They are aware, and they are working on improvements to RT2 all the time. It should be out by the end of the year, but I cannot make promises. We can see if we can get it in for kit 109. In the meantime, you will have to live with the limitation, or revert back to RT1 or PT.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.