Autodesk / Autodesk/maya-usd

Renaming References 'bakes in' material relationships

Open
#3,303 4 comments 0 reactions 1 assignee Claimed by @santosg87 View on GitHub
bug
Dominant language
Wolfram Language
Stars
905
Forks
223
Avg merge
2d 9h
Merged PRs (30d)
17

Description

If I reference in a USD prim and save my USD stage, I end up with a file like...

```
#usda 1.0
(
defaultPrim = "root"
)

def Xform "root" (
kind = "group"
)
{
def Xform "world"
{

def Xform "prop"
{
def Xform "bowling_ball" (
prepend references = @C:/path/to/surfaced_bowling_ball_asset.usd@
)
{
}
}
}
}
```

If I then rename the "bowling_ball" prim that prepends the reference (to "renamed_bowling_ball"), the USD stage now looks like...

```
#usda 1.0
(
defaultPrim = "root"
)

def Xform "root" (
kind = "group"
)
{
def Xform "world"
{

def Xform "prop"
{
def Xform "renamed_bowling_ball" (
prepend references = @C:/path/to/surfaced_bowling_ball_asset.usd@
)
{
over "geo"
{
over "bowling_ball_GRP"
{
over "bowling_ball_GRP"
{
over "bowling_ball_GEO"
{
rel material:binding =
}
}

over "mat"
{
over "MAT_bowling_ball"
{
token outputs:mtlx:surface.connect =

over "MAT_bowling_ball"
{
color3f inputs:base_color.connect =
float inputs:coat.connect =
vector3f inputs:normal.connect =
}

over "mtlxrange1"
{
color3f inputs:in.connect =
}

over "mtlxhsvadjust1"
{
color3f inputs:in.connect =
}

over "mtlxrange2"
{
vector3f inputs:in.connect =
}

over "mtlxnormalmap1"
{
vector3f inputs:in.connect =
}
}
}
}
}

}
}
```

This is then causing problems further down the pipe, because `surfaced_bowling_ball_asset.usd` might have its surfacing updated, or material bindings changed, but these changes won't be reflected in this USD stage since these opinions have been authored on a higher level.

It's superficially similar to a previous issue (fixed in 0.24.0 I think?) where duplicating a referenced prim would cause its contents to be written into the stage that was referencing it, and I think this throw us off the scent in terms of recognising this as an issue for a while. But this issue is certainly present in at least 0.24.0 and 0.23.0. Since there's no visual indication of a problem in Maya, we have ended up authoring quite a lot of USD files out of Maya now that contain enormous quantities of these opinions before realising it was actually happening.

**Steps to reproduce**
Steps to reproduce the behavior:
1. Create a new USD stage.
2. Create a prim and prepend a reference to it. Load the payload if necessary. This prim must have material bindings for this problem to occur.
3. Check the USD stage's ASCII to confirm it is 'clean' (ie like the first example above)
4. Rename the prim by double-clicking it in the outliner and giving it a new name.
5. Check the USD stage's ASCII. It will now material-related relationships/connections authored into the stage as 'over' opinions.

**Expected behavior**
I'd expect the result of renaming a reference with such material relationships to be the same as renaming one without them (i.e it looks like the first example above). And, in fact, if you unload payloads (such that the contents of the reference are no longer visible) and rename the prim, this is exactly what happens. It only seems to author these opinions when the various material connections are loaded in the stage.

**Specs (if applicable):**
- Windows 10
- Maya 2022.4
- Maya USD 0.24.0 as per the downloadable binaries
- The materials are all authored in Houdini, but they're MatX.

**Additional context**
For now we're getting around this problem by running some code that checks the stage's root layer for material binding relationships and removing them just prior to exporting USD stages. This seems to avoid the issue 'downstream' for now, but the resulting files are a bit of a bloodbath of empty over's and material connections that we'd ideally not have hard coded into our layout USD stages.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.