Write non-connected uvSet names

[dgovil]

This change makes it so that the Maya export will write the uv set names as default values in addition to the connected value.

While the connected value provides a lot of convenience, we're finding that several applications do not handle the connected case. This unfortunately also includes some older versions of RealityKit, but also other DCC.

We're working to resolve this in those other applications and our own libraries, but in the meantime, this increases the compatibility with applications that weren't expecting a connection here.

Since the connection still exists, it means we preserve the existing behaviour if people want to override the value set.

[BigRoy]

Could this start influencing how e.g. a renderer like Arnold interprets shaders for a mesh since now it always appears forced to a specific UV set? I assume then that previously a texture could be used in a shader that is applied to two objects with a different "current UV set" (defined on the geom?) maybe? Not sure how that works out in practice but it's possible with maya shaders at least so was wondering whether we might hit an edge case there.

[dgovil]

It shouldn't have any difference in render time behaviour.
Basically earlier it was set so that the UVSet was a connection to an attribute instead of directly on that input. That attribute that stored the UVSet name was still on the Material itself.

The only advantage was that you could override the UVSets across the material in one spot (in theory anyway, often you'd have multiples pointing to the same thing anyway). With this change, tools that followed the connection wouldn't be affected (since the value is still there), but DCC's that don't would still be able to look up the UVSet.

[JGamache-autodesk]

Can you hide that code behind an env var so only clients that knowingly export to one of those DCC get affected? The generated USD is correct, but I am a bit worried with bloat and absence of support for multiple UV sets.

[dgovil]

Sure. What would you like the env var to be called?

[JGamache-autodesk]

USDMAYA_PROVIDE_DEFAULT_TEXCOORD_PRIMVAR_NAME ?

[dgovil]

Thanks. I'll make that change.

I was curious though, when you said "the absence of support for multiple UV Sets", would this not just have the same support for multiple UV Sets as the connection only method would? Since it's setting the value to the same thing that the connection's target was being set to anyway.

I don't think there should be a loss in capability, but maybe I'm missing another place where the connections target value is set for an alternate UV Set?

[JGamache-autodesk]

We initially set a default value of "st" (or equivalent), but there is very interesting post-processing code in _UVMappingManager that will correctly remap complex UVset scenarios, including multiple UV sets as tested in testExportRenamedUVSetMappings.

[dgovil]

Ah I must have missed that. I'll update the PR to use that and update the test as well to check for these changes. Thanks for the pointer.

[dgovil]

@JGamache-autodesk , okay updated the code to put it behind an environment flag and support multiple UV Sets based on the manager. Used MAYAUSD_PROVIDE_DEFAULT_TEXCOORD_PRIMVAR_NAME to be consistent with the other flags (MAYAUSD instead of USDMAYA)

I also added a test + assets because I didn't see one that tested just singular material with UVSets in the way we use them.

Let me know if I should add documentation somewhere too. I wasn't sure where to do so.

[JGamache-autodesk]

LGTM!

[seando-adsk]

@dgovil I ran the preflight for you but there is a test failure on testUsdExportUVSetMappings

[dgovil]

Ah that's odd. I'll take a look. Thanks!

[dgovil]

Okay, I pushed an update to the Maya sample file that isolates things and removes some of the elements that were causing issues in the log. I believe it should work now.

[JGamache-autodesk]

Might indeed help. You also might want to search and replace the texture file paths to make them relative since the images are in the same folder as the scene file.

[dgovil]

Removed the absolute paths , but also had to remove some more setup stuff that seems to only be compatible with Maya 2024. Tried loading the file in Maya 2022 and it loads without warnings/errors so I'm hopeful that's the last of the attributes I missed cleaning out. (I wish there was a Maya file validator :-) )

@seando-adsk if you can run the preflight again when you get a chance. I'm hopeful this is the last failure in the test asset

[seando-adsk]

@dgovil Seems like testUsdExportUVSetMappings is still failing.

[dgovil]

Apologies for that, it's just difficult to reproduce the CI tests locally since the tests don't fail here due to the difference in Maya configuration .

I'll try again or see if I can make a file that's generated procedurally.

[JGamache-autodesk]

For examples of procedurally generated files: grep for any test Python file containing the string vertexUvOne.

[dgovil]

@seando-adsk Should be resolved now. That one was my bad, I'd missed one commit when cherry-picking my changes over that moved the environment variable to the CMake file instead of inside the unitTest.

I also removed some Python 3 specific code since I'd forgotten that Maya 2022 has a Python 2 only variant for Linux and Windows.

Could you run the pre-flight again when you're able to. Thank you, and apologies again.