-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assign to component tags #2963
Assign to component tags #2963
Conversation
- Automatically adjust the family name when assigning. - Use a modern undo/redo framework to fix bugs.
@@ -735,7 +735,7 @@ static const std::vector<MayaUsd::ufe::SchemaTypeGroup> getConcretePrimTypes(boo | |||
bool sceneItemSupportsShading(const Ufe::SceneItem::Ptr& sceneItem) | |||
{ | |||
#if PXR_VERSION >= 2108 | |||
if (MayaUsd::ufe::BindMaterialUndoableCommand::CompatiblePrim(sceneItem).IsValid()) { | |||
if (MayaUsd::ufe::BindMaterialUndoableCommand::CompatiblePrim(sceneItem)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some signatures were changed. This one now only returns a boolean.
@@ -1239,24 +1239,23 @@ Ufe::UndoableCommand::Ptr UsdContextOps::doOpCmd(const ItemPath& itemPath) | |||
#endif | |||
#if PXR_VERSION >= 2108 | |||
else if (itemPath[0] == BindMaterialUndoableCommand::commandName) { | |||
return std::make_shared<BindMaterialUndoableCommand>(fItem->prim(), SdfPath(itemPath[1])); | |||
return std::make_shared<BindMaterialUndoableCommand>(fItem->path(), SdfPath(itemPath[1])); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And the constructor now takes a Ufe path.
} | ||
|
||
BindMaterialUndoableCommand::BindMaterialUndoableCommand( | ||
const UsdPrim& prim, | ||
Ufe::Path primPath, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was about to say that keeping a Ufe::Path was better than keeping a Stage/SdfPath for undo/redo, but then noticed that since I modernized to use a UsdUndoBlock, this is not relevant anymore.
} | ||
bindingAPI.Bind(material); | ||
if (auto subset = UsdGeomSubset(prim)) { | ||
subset.GetFamilyNameAttr().Set(UsdShadeTokens->materialBind); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was the only required change to make assignment work and have the material display in the viewport.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, but as I asked, IDk what are the implication of changing the family name on an existing subset.
@@ -312,7 +313,6 @@ def testAddNewPrim(self): | |||
cmds.file(new=True, force=True) | |||
|
|||
# Create a proxy shape with empty stage to start with. | |||
import mayaUsd_createStageWithNewLayer | |||
proxyShape = mayaUsd_createStageWithNewLayer.createStageWithNewLayer() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TY, it annoyed me too in past ;)
ufeCmd.execute(cmd) | ||
|
||
self.assertEqual(topSubset.GetFamilyNameAttr().Get(), "materialBind") | ||
self.assertTrue(topSubset.GetPrim().HasAPI(UsdShade.MaterialBindingAPI)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it was discussed internally, but i'm not sure what is better: change the name of the set or create a new set? The family name, according to USD, is used to group tags that are related, so changing it changes the group-of-subset composed of with members with the same family name.
In this case we're the one generating the componentTag, but it feels bad to now have 5 side with componentTag family name and one with the material binding one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The end result of the discussions is that we try to keep the number of subsets to a minimum (hence the in-place family renaming), and a subsequent PR will also make sure that the number stays as stable as possible across import/export.
- Maya: create poly sphere, select half the faces and apply material (no component tags on the mesh gets created)
- Export to USD: creates a geom subset with same name as material and some extra roundtripping info
- Import to Maya: the poly mesh does not get a new component tag but the face material assignment is preserved
- Export again to USD: number of geom subsets stays stable.
or
- Maya: create poly cube (automatically gets component tags)
- Export to USD: tags exported as subsets. Extra info added to specify source.
- In MayaUSD: assign material to one geom subset (this PR). Rename family and add material relationship.
- Import from USD: We create both a mesh component tag (since we remember the origin) and a face-assigned material (since we want to see material in viewport). Need to add info to mark both as coming from the same geom subset.
- Export again to USD: number of geom subsets stays stable because we recognize that the material subset is the same as the mesh subset (unless editing in Maya caused them to diverge).
This means the geom subset import/export will no longer be hardcoded to only support "componentTag" family name.
- All families are supported. Default if family is unknown is still "componentTag"
- There will be a way to assign a family name using USD dynamic tags on the Mesh (TBD). The import/export code will use that.
{ | ||
if (!_stage || _primPath.IsEmpty() || _materialPath.IsEmpty()) { | ||
if (_primPath.empty() || _materialPath.IsEmpty()) { | ||
return; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IDk if it warrants a warning or some other user feedback when the arguments are not valid?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the error handling scheme is still CTOR throws if command cannot execute
then I agree this test should be moved to the constructor and throw accordingly. The execute() function should assume these are valid. Will fix that this afternoon.
|
||
auto prim = ufePathToPrim(_primPath); | ||
if (!prim.IsValid()) { | ||
return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment about all these early returns vs giving user feedback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would only want to know the rationale behind the decision to modify family names before approving.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice improvements, LGTM.
That is required by USD:
There is a separate story logged as MAYA-128503 to reconcile the two known Maya geom subsets sources on import/export/rountrip. |
My question was not about the name itself, but the decision to modify the subset family name instead of creating a new subset with a different family name. |
2e2d9bb
if (!BindMaterialUndoableCommand::CompatiblePrim(parentItem)) { | ||
const std::string error = TfStringPrintf( | ||
"Assign new material: Skipping incompatible prim [%s] found in selection.", | ||
Ufe::PathString::string(parentItem->path()).c_str()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found in the unit tests where the first new material ended up in the selection list for the second assign new material call.
Allows assigning materials to component tags
Will set family to "materialBind" if required
That is part 1 of 2. The second part requires being able to roundtrip these assignments thru import/export without gaining or losing any component tags.