AcademySoftwareFoundation
Lama shader input name mismatches to Prman
Hi,
I've got Renderman 26.1 here and setting up MaterialX support for Gaffer. I've noticed that there is a naming discrepancy in some of the Lama shaders.
In MaterialX LamaConductor there is anisotropyRotation and anisotropyDirection but for LamaDielectric it is rotation and direction, but the Renderman implementations it uses the one with the anisotropy prefix for the names in both. This is the same for conductorNormal/dielectricNormal in Renderman, but MaterialX simply has normal. I am not sure if this is intentional or if these are an oversight.
I think the prefixed versions would be preferred, if only for the fact that normal is a reserved name and dealing with the 1 suffixes isn't too fun. :)
Kind regards -Alex
Great catch, @boberfly, and we should definitely address these differences in a future release. If it's acceptable to you, I'd recommend that we address this for MaterialX v1.40, so that we can leverage our version upgrade system, allowing existing assets to automatically upgrade to the new node signatures. I'm aware of production tools that already support the current node signatures for MaterialX Lama, and our usual approach is to consider assets created with any previous release to be valid in all future releases.
Hi @jstone-lucasfilm thanks for looking into this. No rush from me, I was just curious if it was intentional - I can work around any translations here with either naming convention.
Not to defer this too much but this reminded me to ask about the updating system. In my current development I am using OpenUSD to query/create MaterialX nodes into the UI so heavily relying on sdr/usdMtlx and not using the native XML document system. I think this way it's problematic due to never triggering the update path eg. I've loaded in 1.38.x graphs from one DCC from OpenUSD schema and ran into issues with not detecting ND_normalmap because it renamed to ND_normalmap_float in 1.39.x so I am currently using pre-processor defines of the MaterialX version and making choices this way, essentially making my own update system. Maybe it's something usdMtlx needs to address when loading in schema, but something I'd just mention here if I'm missing something.
Cheers
@boberfly There are updates to usdMtlx and hdMtlx in OpenUSD 25.02 and 25.05, that aim to address supporting the MaterialX versioning.
There is a new USD applied API schema that can be used to encode the MaterialX version in UsdShade graph. The MaterialX file format plugin has been updated to apply this schema, but other tools will need to be updated when they adopt MaterialX 1.39. There is corresponding functionality in hdMtlx where the MaterialX document is reconstructed from the Hydra material data, which restores the recorded MaterialX version and then passes that document through the MaterialX upgrade function, before continuing on to generate the shaders.
The original PR for this work is here, though I think Pixar made some changes as they merged the work. @klucknav is a great person to reach out to if you need more up to date information on the state of this work.
