maya-usd-git-sync[bot]
commented
7 months ago Issue synced internally to EMSUSD-650
Open bram0101 opened 3 years ago
maya-usd-git-sync[bot]
commented
7 months ago Issue synced internally to EMSUSD-650
Is your feature request related to a problem? Please describe. Shading groups in Maya have the normal surface shader input, but also renderer specific surface shader inputs (the same goes for volume and displacement shaders). This allows for a simple material in the normal surface shader input, which is shown in the viewport, and the full material in the renderer specific input, which is used when rendering. This is useful when not all shading nodes are supported in the viewport, but you still want a preview of the material. Renderman for Maya even does this by default. Currently Maya-USD does not export the renderer specific materials, but only the normal surface shader material. Especially for workflows that rely solely or mostly on Maya, the ability to have a material for the viewport and another material for the renderer is hugely beneficial to the user's experience.
Describe the solution you'd like When exporting, the user may select, from a list of options, Maya-USD's behaviour when it comes to exporting materials. To these options, I propose to add two new option that would work as follows: With pxrUsdPreviewSurface The shading graphs connected to the normal surface, volume and displacement shader inputs are seen as preview materials and will be converted to fully USD compliant materials that would be supported on every 3rd party application supporting USD. This way the file should still be able to be opened in other applications (for example Houdini in order to do some FX simulations, which then can be brought back into Maya) and show the preview materials.
The shading graphs connected to any other inputs (which we are assuming to be renderer specific inputs) are stored as direct representations, so that when imported again, the resulting shading graph is identical to the original shading graph. Instead of just looking at the Arnold specific inputs and forcing render engines to register their renderer specific inputs, Maya-USD simply goes through every input attribute and if a shading graph is connected to it, it will export that. This way, all render engines are implicitly supported. The exported graphs will still be Maya specific (due to being direct representations), however practically all render engines have code to convert Maya shading graphs to their internal formats, so in theory it should be easy for render engines to support this. Otherwise, the render engine can always use the pxrUsdPreviewSurface material.
As-Is All shading graphs connected to the shading group are stored as direct representations (as-is), so that when imported again, the resulting shading graph is identical to the original shading graph. This behaviour is exactly the same as With pxrUsdPreviewSurface, but instead of converting the normal surface, volume and displacement shading graphs to fully USD compliant pxrUsdPreviewSurface materials, it will export these shading graphs as direct representations. This does make the USD file fully Maya specific. However, this is just another option to use and is very useful for fully Maya-based workflows.
Optional addition to this Currently this feature would create Maya specific shading graphs. Render engines should be able to some-what-easily add support for this. However, an additional feature to this, that would be nice to have, would be to allow render engines to register an additional translator when exporting the renderer specific shading graphs. Simply put, a render engine may register a list of attributes together with its translator. When Maya-USD is going through the input attributes, to export the shading graphs, and the input attribute it is currently exporting has been registered by a render engine, it will call the render engine's translator to export the shading graph, instead of creating a Maya specific graph (like it would do normally). Obviously, the render engine would also have to provide a translator for importing.
When combined with the With pxrUsdPreviewSurface option, this additional feature would create USD files that are no longer Maya specific, but now renderer specific. Another 3rd party application could also provide such a translation feature and the, now renderer specific, USD file can be imported without any problems. For example, Renderman could provide a translator. We export an asset from Maya to USD. The preview material is converted to pxrUsdPreviewSurface and the Renderman translator exports the Renderman specific shading graph. In Houdini, Renderman could also add such a translator (provided that Houdini's USD plugin also adds such a translation feature) and we can import the USD file and the shading graphs are reconstructed as if we made the asset in Houdini to begin with. We can then modify the asset in Houdini, export it again and import it in Maya. We still have a preview material (in the form of pxrUsdPreviewSurface) for the viewport and the full Renderman specific shading graph. While more complicated to implement, it would make USD more universal (badum tss).
Describe alternatives you've considered The described workflow where you have a preview material for in the viewport and the full material for rendering, is currently impossible to achieve with Maya-USD. The only alternative would be to not use Maya-USD or not use this workflow at all. Neither of these are ideal.