-
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
Add contextual menu to create material nodes #2466
Conversation
- Puts the material in the right location - Supports undo/redo - Added unit test
@@ -500,148 +650,6 @@ class ClearAllReferencesUndoableCommand : public Ufe::UndoableCommand | |||
const std::string ClearAllReferencesUndoableCommand::commandName("Clear All References"); | |||
const MString ClearAllReferencesUndoableCommand::cancelRemoval("No"); | |||
|
|||
#if PXR_VERSION >= 2108 | |||
class BindMaterialUndoableCommand : public Ufe::UndoableCommand |
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.
Moved to UsdUndoMaterialCommands.cpp
@@ -892,77 +900,90 @@ Ufe::ContextOps::Items UsdContextOps::getItems(const Ufe::ContextOps::ItemPath& | |||
|
|||
// Top level item - Add New Prim (for all context op types). | |||
items.emplace_back(kUSDAddNewPrimItem, kUSDAddNewPrimLabel, Ufe::ContextItem::kHasChildren); | |||
|
|||
if (!fIsAGatewayType) { |
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.
Moved upwards yo keep the Materials menu in last position.
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.
LGTM. Made some comments/questions.
Tested against Maya 2022
return false; | ||
} | ||
materialOutput | ||
= UsdShadeMaterial(materialPrim).CreateSurfaceOutput(shaderNodeDef->GetSourceType()); |
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 I understand correctly this will add the appropriate surface output to the material node, but shouldn't you also be adding the displacement and volume outputs?
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.
Why do that if there is nothing to be connected to those outputs?
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 agree that the material node won't be connected to those outputs, but can't a user use the editor to connect shaders to displacement if you created it?
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 would be the editor's responsibility to either automatically create the right ports, or offer options to create them when dealing with displacement shaders. The editor should not dictate what this command is doing.
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.
But shouldn't all materials have surface, displacement, volume ports? I'm not following why you think this is a special case. It's not like in the future users will create displacement shaders as a different type, they will still just create a standard surface and connect shaders to the displacement port.
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.
Displacement and volume attributes appear in your editor because UFE will allow browsing unauthored attributes. They do not exist in the UFE stage until you explicitly set their values or connect them.
The outputs for MaterialX context are another problem, because they are not in the default schema and escape UFE detection. But this is an issue for a later time, when we add knowledge on how to connect to a material port. I suspect the attempt to connect to outputs:displacement will be redirected to outputs:mtlx:displacement directly in the MayaUSD implementation of the connect command after looking at the return value of GetSourceType() on the shader we will be trying to connect to the material.
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'm a bit concerned about the additional complexity caused by attempting to recover from failed undo. I think that handling undo failure at this level is not buying us much, and we should let the DCC app (Maya) deal with it, which hopefully should be by clearing the undo stack.
lib/mayaUsd/ufe/UsdContextOps.cpp
Outdated
} | ||
|
||
protected: | ||
Ufe::UndoableCommand::Ptr _creationCmd; |
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.
Should be const, i.e.
const Ufe::UndoableCommand::Ptr
static const std::string kDefaultMaterialScopeName("mtl"); | ||
} // namespace | ||
|
||
void UsdUndoAssignNewMaterialCommand::execute() |
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.
Feels like this should be a Ufe::CompositeUndoableCommand.
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 used has a
because is a
leads to a diamond shape inheritance with InsertChildCommand.
Managing the undo of a composite command could be challenging. But something must be done; otherwise, the composite undo() can try to undo a step which was never done i.e. failure in the undo composite step. A good approach is that the composite command only keeps a state of what was done. For example, there is a composite command with three steps. Let say that the composite do() fails but only successfully did the first two steps (i.e. the third step failed). The composite undo() should not try to undo the third step; otherwise, it will also fail. |
@@ -79,8 +79,10 @@ def testDuplicateProxyStageAnonymous(self): | |||
self.assertEqual(True, "-session" in stage.GetSessionLayer().identifier) | |||
self.assertEqual(True, "anonymousLayer1" in stage.GetRootLayer().identifier) | |||
|
|||
# add proxyShapeItem to selection list | |||
ufe.GlobalSelection.get().append(proxyShapeItem) |
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.
Worked because Add Prim left the selection empty. No longer the case.
I would distinguish initial execution (execute()) from undo() and redo(). If initial execution fails, it should be dealt with outside of undo / redo, so that the undo stack is preserved. If a step in the composite undo fails, it should throw an exception, because the state of the undo stack is unknown and possibly corrupt, and the undo stack should be cleared. |
I don't think. The behaviour must be the same in both situation (single or composite commands). A user, the Maya undo queue, etc. must work exactly the same way without knowing if it's a single command or a composite command. That's the composite pattern -- or -- like a transaction (perhaps too much for now) i.e. all steps succeeds (or all steps are reverted). |
@JGamache-autodesk Did you discuss the changes (especially the selecting prim part) with Natalia? |
@seando-adsk Yes, I checked this morning and Natalia is OK with auto-selecting prims. |
Requirements:
(prim creation also benefits from auto-selection)