MAYA-123720 - As a user, I'd like Display Layer membership to survive the 'Edit As Maya Data' workflow #2628
Conversation
lib/mayaUsd/ufe/Utils.h
Outdated
| @@ -231,5 +231,25 @@ Ufe::Selection recreateDescendants(const Ufe::Selection& src, const Ufe::Path& f | |||
| MAYAUSD_CORE_PUBLIC | |||
| std::vector<std::string> splitString(const std::string& str, const std::string& separators); | |||
|
|
|||
| class PullExtras | |||
There was a problem hiding this comment.
Do we need two different classes? How about a single class that can handle both cases (Maya->USD and USD->Maya). Just have two sections of methods for each case. And I guess you were thinking that in the future we could add other types of extras (now we have DisplayLayers)? The names "Pull/Push" are specific to your operation, but we'll add this for duplicate usd prim. Can we have a generic name?
There was a problem hiding this comment.
@seando-adsk The two classes share neither data members nor methods, so I don't see a reason to merge them. As for renaming, would ReplicateExtrasToUSD/ReplicateExtrasFromUSD wouldwork for you?
There was a problem hiding this comment.
Yes those names are better.
lib/mayaUsd/ufe/Utils.h
Outdated
| void initRecursive(Ufe::SceneItem::Ptr); | ||
| void processItem(const Ufe::Path& path, const MObject& mayaObject); |
There was a problem hiding this comment.
These methods need comments as to what they are doing.
|
I'll wait until @ppt-adsk has had a chance to review this before merging. |
| @@ -67,6 +68,9 @@ class UsdMayaPrimUpdaterContext | |||
| MAYAUSD_CORE_PUBLIC | |||
| MDagPath MapSdfPathToDagPath(const SdfPath& sdfPath) const; | |||
|
|
|||
| mutable MayaUsd::ufe::ReplicateExtrasFromUSD _pullExtras; | |||
There was a problem hiding this comment.
These mutable data members feel uncomfortable. Does the following make any sense:
- initRecursive() writes into the map. Can we transform it into a static creator method?
- processItem() and finalize() read from the map. They can be made const methods.
That way, you can pass in the ReplicateExtras objects as const into the context, make them const data members, and provide const accessors to them, keeping the PrimUpdaterContext read-only.
Hope I didn't skip over some crucial detail...
There was a problem hiding this comment.
Your plan will not fully work because ReplicateExtrasToUSD::processItem writes into the map.
There was a problem hiding this comment.
O.K., FromUSD works, ToUSD does not :) Let me think about it some more.
There was a problem hiding this comment.
Here's a tweak to my suggestion to get it to work: everything as per above, but ReplicateExtrasToUSD::processItem() does a const cast if it needs to write into the map. Alternately, the map is mutable. I think this is acceptable, as the fact that processItem() is writing into the map is an invisible implementation detail. In that way, the prim updater context can appear to be conceptually read-only. What do you think?
No description provided.