maya-usd icon indicating copy to clipboard operation
maya-usd copied to clipboard
verified publisher icon Autodesk

Running LookdevXMaya with a custom OpenUSD/MayaUSD build

Open boberfly opened this issue 7 months ago • 3 comments

Describe the bug When building to match (more or less) Maya's 2026 OpenUSD stack, it seems as though MaterialX*MayaUSD.dll versions are slightly different from vanilla MaterialX releases, enough to make LookdevXMaya.mll not run and DependenciesGui.exe shows mayaUsdAPI.dll that has built is expecting some symbols out of it that I assume a vanilla MaterialX wouldn't have...

Steps to reproduce Steps to reproduce the behavior:

  1. Build OpenUSD (in this case v24.11 or v25.02)
  2. Build MayaUSD
  3. Copy the MaterialX*MayaUSD.dll from official builds and path them so LookdevXMaya can use this.
  4. Run Maya 2026 with this custom build pathed to the .mods
  5. Try to load LookdevXMaya.mll

Expected behavior LookdevXMaya loads and is compatible with custom OpenUSD builds.

Attachments

Specs (if applicable):

  • OS & version - Windows 10
  • Compiler & version - Visual Studio 17 2022 v143
  • Maya version - Maya 2026
  • Maya USD commit - release/v0.31.0
  • Pixar USD commit - release (v24.11)
  • MaterialX 1.38.10 (vanilla release)

Additional context I did notice devkit.zip in official MayaUSD releases does have this custom MaterialX and can be linked to. If I link to this MaterialX with MayaUSD somehow, is that easy to set via CMake somehow? And perhaps I can leave alone the vanilla MaterialX+OpenUSD intact, but just link MayaUSD to this custom MaterialX as a workaround?

Thank you

boberfly avatar May 06 '25 00:05 boberfly

https://github.com/boberfly/maya-usd/commit/ef6b5a104b82ec4c305acd2558bf495c65e0173c

A plausible way to "make it work". This has an OpenUSD built with a vanilla MaterialX, but when building MayaUSD I pass an explicit MaterialX with the _MayaUSD suffix and namespace from devkit.zip. Unfortunately I need to embed hdMtlx and the utils.cpp from usdMtlx for this to work (when returning MaterialX types, it has the namespace on it so it needs to match the MaterialX version).

I don't expect this to be a real solution, but it might bring some insight into how to support custom OpenUSD builds with a vanilla MaterialX and the MaterialX MayaUSD one side-by-side and have LookdevXMaya work.

Cheers

boberfly avatar May 06 '25 10:05 boberfly

The USD v24.11 build that we used for Maya 2026 is not vanilla USD. We have extra commits, including MaterialX updates. You can view our commits from the build.md page. Look at the column titled "USD source for MayaUsd".

As you saw we also ship devkit.zip that contains the headers/libs of our USD build. This is specifically so that customers can build the MayaUsd repo using the same USD build that we used. You should simply need to extra this devkit.zip and then if using the build.py from our repo pass the flag --pxrusd-location and point it to that USD folder in your MayaUsd install (where you extracted devkit.zip).

Sean

seando-adsk avatar May 06 '25 14:05 seando-adsk

Hi @seando-adsk thank you for the reply.

Yep I will be syncing with this version next. I still think this will be still an issue as the MaterialX that ships with MayaUSD has a namespace and suffix on the end of the libraries, while that branch in the build.md will be using 1.38.10-OpenPBR which wouldn't have the namespace/suffix, so I think what I've tweaked on my end is a way around it (verified that I could load in LookdevXmaya with both MaterialX libraries linked in).

Cheers

boberfly avatar May 07 '25 01:05 boberfly