-
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
MAYA-129061 - Refactor material commands. #3056
MAYA-129061 - Refactor material commands. #3056
Conversation
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.
Well done! This will help.
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.
Since this was just refactoring existing code I assume there is no new unit test(s) that are needed?
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.
Yes, the refactored code is covered by the existing tests.
UsdUndoCreateMaterialsScopeCommand
is now separated out, so if we want that, we could also test it independently by creating a Python binding for it. However, it is used by UsdUndoAssignNewMaterialCommand
and, thus, already covered by e.g. this test.
One addition that is not used or tested yet is UsdUndoAddNewPrimCommand::sceneItem()
.
|
||
Ufe::SceneItem::Ptr UsdUndoAddNewPrimCommand::sceneItem() const | ||
{ | ||
return Ufe::Hierarchy::createItem(newUfePath()); |
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.
This method is currently not used or tested. However, I'm not sure if it can easily be tested right now, since UsdUndoAddNewPrimCommand
is tested though Ufe::ContextOps::doOpCmd()
(see here), which returns a UndoableCommand::Ptr
, not a Ufe::SceneItemResultUndoableCommand()
.
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 made the material commands call UsdUndoAddNewPrimCommand::sceneItem()
instead of manually calling Ufe::Hierarchy::createItem()
on UsdUndoAddNewPrimCommand::newUfePath()
. This makes the code a little more tidy and ensures that UsdUndoAddNewPrimCommand::sceneItem()
is covered by existing tests. See 088f54ab81ccfb4ddc941d5c120888d34dee9fea.
088f54a
fd94667
to
fd6d428
Compare
Rebase on dev as an attempt of fixing clang-format issues on code I have not touched. |
Make UsdUndoAddNewPrimCommand derive from SceneItemResultUndoableCommand. This allows UFE clients to access the newly created prim by calling SceneItemResultUndoableCommand::sceneItem().
In UsdUndoMaterialCommands, factor out the code related to materials scopes into separate commands and functions. This will allow reusing them and is required by future work (MAYA-128151).
…hat it is covered by tests.
fd6d428
to
355deb1
Compare
Rebase on dev again to fix formating. |
In UsdUndoMaterialCommands, factor out the code related to materials scopes into separate commands and functions. This will allow reusing them and is required by future work (MAYA-128151).
Also, make
UsdUndoAddNewPrimCommand
derive fromSceneItemResultUndoableCommand
. This allows UFE clients to access the newly created prim by callingSceneItemResultUndoableCommand::sceneItem()
.