MAYA-104985 Allow multiple export converters to co-exist in useRegistry export #721
Conversation
JGamache-autodesk
changed the title
…port_render_context # Conflicts: # lib/mayaUsd/fileio/jobs/jobArgs.cpp # lib/mayaUsd/fileio/shading/shadingModeRegistry.h # plugin/adsk/scripts/mayaUsdTranslatorExport.mel
There was a problem hiding this comment.
The changes look mostly ok to me, with a few notes sprinkled throughout.
My main issue is that I think we need to clarify the terminology we're using and be explicit about where we're aligning with terms in USD and where (if anywhere) we're not. I think the intent is for the usage of "render context" here to align with the "renderContext" concept in UsdShade, so I don't think the replacement of "universal" with "preview" here is appropriate. For the most part I think I'd be comfortable with this if we just used "universal" instead.
JGamache-autodesk
changed the title
…port_render_context # Conflicts: # lib/mayaUsd/fileio/shading/shadingModeRegistry.cpp # test/lib/usd/translators/CMakeLists.txt
There was a problem hiding this comment.
Looks good to me now! Thanks for re-working all this, @JGamache-autodesk! I think it made everything a lot clearer.
I had just a few notes on the tests that I was a little confused by.
JGamache-autodesk
added
the
ready-for-merge
The material exporter now supports multiple exporter classes for the same Maya dependency node type.
A new parameter was added to the export command to specify a converter on export and the registry will choose the exporter that best matches the converter found in the export options.
A test exporter was written to make sure the mechanism works, but no new functionality was added to the current exporters.