MAYA-106486 Handle UV linkage on material export #876

JGamache-autodesk · 2020-10-30T15:18:03Z

We now explore the UV linkage and make sure the UV stream name in the material matches the UV set name on the shape.
We will create as many material specializations as needed to match the shape streams in case of UV stream names inconsistency in a group of shapes sharing a single material.
We no longer automatically rename "map1" to "st" since the UV streams in the material will now be correctly set. You can use the following pair of environment variables to bring back the renaming behaviour: MAYAUSD_EXPORT_MAP1_AS_PRIMARY_UV_SET and MAYAUSD_IMPORT_PRIMARY_UV_SET_AS_MAP1.

We now explore the UV linkage and make sure the UV stream name in the material matches the UV set name on the shape. We will create as many material specializations as needed to match the shape streams in case of UV stream names inconsistency in a group of shapes sharing a single material. We no longer automatically rename "map1" to "st" since the UV streams in the material will now be correctly set.

JGamache-autodesk · 2020-10-30T15:19:59Z

lib/mayaUsd/fileio/shading/shadingModeExporterContext.cpp

+    UsdPrim materialPrim = MakeStandardMaterialPrim(assignmentsToBind, name);
+    BindStandardMaterialPrim(materialPrim, assignmentsToBind, boundPrimPaths);
+    return materialPrim;
+}


This function is split in two parts since the useRegistry exporter now wants to have the material exported before the binding is done.

JGamache-autodesk · 2020-10-30T15:20:30Z

lib/mayaUsd/fileio/shading/shadingModeExporterContext.cpp


        UsdPrim materialPrim = material.GetPrim();

-        // could use this to determine where we want to export.


The binding code exported in a separate function.

JGamache-autodesk · 2020-10-30T15:23:31Z

lib/mayaUsd/fileio/shading/shadingModeExporterContext.cpp

+        const VtIntArray& faceIndices = iter.faceIndices;
+        const TfToken&    shapeName = iter.shapeName;
+
+        const UsdShadeMaterial& materialToBind = uvMappingManager.getMaterial(shapeName);


Main difference in the extracted code for binding materials is here. We ask the mapping manager for the material to bind. In case of inconsistent texcoord naming in the shape set, this function can return specialized materials that fit the needs of the current shape.

JGamache-autodesk · 2020-10-30T15:25:47Z

lib/mayaUsd/fileio/utils/meshReadUtils.cpp

-            uvSetName = UsdMayaMeshPrimvarTokens->DefaultMayaTexcoordName.GetText();
-            createUVSet = false;
-        } else if (!hasDefaultUVSet) {
+        if (!hasDefaultUVSet) {


The removes the automatic "st"-> "map1" renaming on import. Should I create an env var for shops that have internal tools that depend on this behavior?

If possible, that would be great. Would allow transitioning over.

Yes, please! Export is more of a concern for us than import (more detail on that below), but it would be good to have a TfEnvSetting we could set for each direction.

JGamache-autodesk · 2020-10-30T15:26:11Z

lib/mayaUsd/fileio/utils/meshWriteUtils.cpp

-        // The UV Set "map1" is renamed st. This is a Pixar/USD convention.
-        TfToken setName(uvSetNames[i].asChar());
-        if (setName == UsdMayaMeshPrimvarTokens->DefaultMayaTexcoordName.GetText()) {
-            setName = UsdUtilsGetPrimaryUVSetName();


The removes the automatic "map1"-> "st" renaming on export. Should I create an env var for shops that have internal tools that depend on this behavior?

Yes, definitely. Having the Maya USD export portion of our asset builds suddenly writing map1 primvars instead of st primvars would be a non-trivial pipeline change for us, so at least for now, we'll need to be able to opt out of that.

Including a setting for import, maybe a pair of TfEnvSettings like this?:

TF_DEFINE_ENV_SETTING( MAYAUSD_IMPORT_PRIMARY_UV_SET_AS_MAP1, false, "Translates the primary UV set in USD to the map1 UV set in Maya. " "When disabled, UV set names are translated directly (st in USD becomes st in Maya)."); TF_DEFINE_ENV_SETTING( MAYAUSD_EXPORT_MAP1_AS_PRIMARY_UV_SET, false, "Translates the map1 UV set in Maya to the primary UV set in USD. " "When disabled, UV set names are translated directly (map1 in Maya becomes map1 in USD).");

Thanks! :)

Yes agreed, having the env variable to make a switch would be useful. Thanks

JGamache-autodesk · 2020-10-30T15:27:52Z

test/lib/usd/translators/testUsdExportUVSetMappings.py

+        setups results in USD data with material specializations:
+        '''
+        expected = [
+            ("/pPlane1", "/blinn1SG_map1_map1_map1", "map1", "map1", "map1"),


No longer renamed to st

mattyjams

We will indeed need TfEnvSettings to be able to fallback to the map1->st translation, particularly for export. But otherwise, looks good to me!

Thanks @JGamache-autodesk!

lib/mayaUsd/fileio/shading/shadingModeExporterContext.cpp

lib/mayaUsd/fileio/shading/shadingModeExporterContext.h

mattyjams · 2020-11-03T01:13:15Z

lib/mayaUsd/fileio/utils/meshReadUtils.cpp

-            uvSetName = UsdMayaMeshPrimvarTokens->DefaultMayaTexcoordName.GetText();
-            createUVSet = false;
-        } else if (!hasDefaultUVSet) {
+        if (!hasDefaultUVSet) {


Yes, please! Export is more of a concern for us than import (more detail on that below), but it would be good to have a TfEnvSetting we could set for each direction.

mattyjams · 2020-11-03T01:23:39Z

lib/mayaUsd/fileio/utils/meshWriteUtils.cpp

-        // The UV Set "map1" is renamed st. This is a Pixar/USD convention.
-        TfToken setName(uvSetNames[i].asChar());
-        if (setName == UsdMayaMeshPrimvarTokens->DefaultMayaTexcoordName.GetText()) {
-            setName = UsdUtilsGetPrimaryUVSetName();


Yes, definitely. Having the Maya USD export portion of our asset builds suddenly writing map1 primvars instead of st primvars would be a non-trivial pipeline change for us, so at least for now, we'll need to be able to opt out of that.

Including a setting for import, maybe a pair of TfEnvSettings like this?:

TF_DEFINE_ENV_SETTING( MAYAUSD_IMPORT_PRIMARY_UV_SET_AS_MAP1, false, "Translates the primary UV set in USD to the map1 UV set in Maya. " "When disabled, UV set names are translated directly (st in USD becomes st in Maya)."); TF_DEFINE_ENV_SETTING( MAYAUSD_EXPORT_MAP1_AS_PRIMARY_UV_SET, false, "Translates the map1 UV set in Maya to the primary UV set in USD. " "When disabled, UV set names are translated directly (map1 in Maya becomes map1 in USD).");

Thanks! :)

HamedSabri-adsk

Looking good! Thanks.

mattyjams · 2020-11-04T17:02:00Z

Just wanted to flag here that after bringing in this change, we're seeing an issue where exported materials specialize themselves. There isn't any UV set re-mapping happening in these cases so I'm not sure what's going on yet, but there looks to be some fallout to this that needs to be addressed.

JGamache-autodesk · 2020-11-04T17:59:36Z

Might be missing an important early return in:

const UsdShadeMaterial& getMaterial(const TfToken& shapeName)
{
    if (_uvNamesToMaterial.empty()) {
        return _material;
    }

But I can not reproduce the issue. Can you send just one erroneous specialization (as text) so I can have a starting point?

JGamache-autodesk requested a review from HamedSabri-adsk October 30, 2020 15:18

JGamache-autodesk assigned ecp-maya-devops-adsk Oct 30, 2020

JGamache-autodesk added the import-export Related to Import and/or Export label Oct 30, 2020

JGamache-autodesk commented Oct 30, 2020

View reviewed changes

JGamache-autodesk unassigned ecp-maya-devops-adsk Oct 30, 2020

MAYA-106486 Update map1/st unit tests

24a920b

JGamache-autodesk assigned ecp-maya-devops-adsk Oct 30, 2020

JGamache-autodesk requested a review from mattyjams October 30, 2020 15:52

mattyjams approved these changes Nov 3, 2020

View reviewed changes

MAYA-106486 Add env var for renaming behaviour

8284d93

JGamache-autodesk assigned ecp-maya-devops-adsk and unassigned ecp-maya-devops-adsk Nov 3, 2020

JGamache-autodesk added the ready-for-merge Development process is finished, PR is ready for merge label Nov 3, 2020

HamedSabri-adsk approved these changes Nov 4, 2020

View reviewed changes

kxl-adsk merged commit 6c27f0a into dev Nov 4, 2020

kxl-adsk deleted the t_gamaj/MAYA-106486/uv_linkage_export branch November 4, 2020 00:51

ysiewappl mentioned this pull request Jan 12, 2021

Fix issue where referenced scenes have incorrect UV set attribute name written out. #1062

Merged

JGamache-autodesk mentioned this pull request Feb 8, 2021

[MAYA-104104] Add import/export cmd documentation #1146

Merged

kxl-adsk mentioned this pull request Mar 17, 2021

UV's missing when exporting to USD #1202

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MAYA-106486 Handle UV linkage on material export #876

MAYA-106486 Handle UV linkage on material export #876

JGamache-autodesk commented Oct 30, 2020 •

edited

Loading

JGamache-autodesk Oct 30, 2020

JGamache-autodesk Oct 30, 2020

JGamache-autodesk Oct 30, 2020

JGamache-autodesk Oct 30, 2020

dgovil Oct 30, 2020

mattyjams Nov 3, 2020

JGamache-autodesk Oct 30, 2020

mattyjams Nov 3, 2020

HamedSabri-adsk Nov 4, 2020

JGamache-autodesk Oct 30, 2020

mattyjams left a comment

mattyjams Nov 3, 2020

mattyjams Nov 3, 2020

HamedSabri-adsk left a comment

mattyjams commented Nov 4, 2020

JGamache-autodesk commented Nov 4, 2020 •

edited

Loading


		UsdPrim materialPrim = material.GetPrim();

		// could use this to determine where we want to export.

MAYA-106486 Handle UV linkage on material export #876

MAYA-106486 Handle UV linkage on material export #876

Conversation

JGamache-autodesk commented Oct 30, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mattyjams left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HamedSabri-adsk left a comment

Choose a reason for hiding this comment

mattyjams commented Nov 4, 2020

JGamache-autodesk commented Nov 4, 2020 • edited Loading

JGamache-autodesk commented Oct 30, 2020 •

edited

Loading

JGamache-autodesk commented Nov 4, 2020 •

edited

Loading