Import/Export Chaser for dependencyNodes (shading) #3694
Replies: 2 comments 1 reply
-
Great idea! We will give this some consideration. |
Beta Was this translation helpful? Give feedback.
-
We have this same issue. My non-ideal way of getting around it is to perform the import under a specific namespace. You can then query the that namespace for the dg nodes you're after. Then remove the namespace afterwards. Not exactly ideal as you still need to do some inspection to find out what nodes are associated with what, and this is all outside of the chaser.. But you can at least find the dg nodes a little more reliably. But yeah wrapping dg nodes into a mapping accessible in the chaser would be great. |
Beta Was this translation helpful? Give feedback.
-
Hello,
In the current implementation of the Chasers, non-Dag nodes are completely ignored.
On our pipeline, we need to do some extra work on shading import and there is no way to know which usd node is the source of which maya node.
We currently have to rely on manual scene inspection and guess it by looking into names. But names are highly unsafe with all the possible auto renaming on clash and the usage of namespaces.
Is it something you have already considered ? I saw you are actively working on the material export #3674
Maybe the chaser could be updated at the same time.
To efficiently do extra steps during import and export we would need on both an argument similar to
DagToUsdMap dagToUsd
(currently available during export) but for dependency nodes:A mapping that would keep track of each maya node vs usd ones (that are not already part of
dagToUsd
).PS: Currently the import chaser has a harder to use implementation since it only gives the root dagNodes and root Prims.
To find matching maya-usd nodes in the hierarchy, we need to do some path inspection and deduction.
Updating it to match the implementation of the export would also be a good improvement.
Beta Was this translation helpful? Give feedback.
All reactions