Optimally rendering the the USD content about maya-usd

[kxl-adsk]

Rendering directly from the USD data model and avoiding translation is the way to go. Your Arnold example can be solved in at least two ways.

1. In refactoring_sandbox we introduced new base proxy shape which all USD proxy shape plugins will base on. This gives us access to USD stage and allows us to support workflows which are independent of the plugin. The next step is to teach mtoa about this base proxy shape (not yet done).
2. In refactoring_sandbox you will find "maya to hydra" plugin from Luma. This new render override plugin will allow you to have both Maya's data model and USD (via again base proxy shape) rendered by the same render delegate (e.g. Arnold render delegate)

[BigRoy]

Thanks.

I guess some focus would be on that mtoa relationship or have it implemented with e.g. V-Ray. Any rough estimate on when focus will shift to point 1) for having it implemented for Arnold within the repository?

Regarding 2), I haven't looked much at what Luma was doing in that regard. But would that mean that it would render it inside Viewport 2.0 using Hydra and merge it with any regular Viewport 2.0 data (e.g. zdepth merge) or will it be a new viewport renderer alltogether? Or is the goal that this maya to hydra will also aid in getting it supported by third-party renderers?

Which makes me wonder to what extend features from for example OpenWalter are intended to be part of the maya-usd repository or whether you'd still need something like Walter on the side.

[kxl-adsk]

Sorry for coming back to you late.

Luma's work introduces a new scene delegate which brings Maya's data model to Hydra. This means things like meshes, curves, etc will not be composite but will fully be handled by selected render delegate (Arnold, Embree, Storm, etc) via render override API in Maya. Composition still happens for some things, like selection highlighting or manipulators.

As for mtoa support - it's on our radar, but I can't give any estimates.

[BigRoy]

Luma's work introduces a new scene delegate which brings Maya's data model to Hydra. This means things like meshes, curves, etc will not be composite but will fully be handled by selected render delegate (Arnold, Embree, Storm, etc) via render override API in Maya.

Is that currently present in one of the branches? :)

As for mtoa support - it's on our radar, but I can't give any estimates.

Sweet. 👍 I wonder if somehow we need to push Chaosgroup too to make sure they adopt it as swiftly as possible, and Redshift and others. Or is that supposed to be a open-source public effort?

[kxl-adsk]

Thx for the reminder about other renderers! And Maya to Hydra is in refactoring_sandbox.

[BigRoy]

@kxl-adsk I saw an actual Arnold render kicking in with the USD proxy shape in this video at 14:45 where later in the video he says something like "the demoed features are available in the repository". I was wondering, this Arnold render delegate. Is that already in one of the branches or is it not public yet?

[kxl-adsk]

Arnold render delegate isn't part of maya-usd repo. Currently, the only public version can be found here https://github.com/LumaPictures/usd-arnold/tree/master/plugin/pxr/imaging/hdAi

[BigRoy]

Thanks. For anyone else interested I also wanted to link this repository for Arnold-USD from Autodesk that recently went public: https://github.com/Autodesk/arnold-usd

In the meantime, I was wondering regarding shader assignments to the USD stage in a proxy. Is there any plans to support this through UFE and have it visualized in the Outliner? Or do you envision it to be separate development in-house for studios and to be done in a custom system, e.g. like OpenWalter (see Basic Maya Assignment video there)?
Or is this something that the Bifrost Graph is planned to tackle and be used as a procedural graph also for shading, similar to Katana, Gaffer and Solaris?

[kxl-adsk]

It's something on our radar, but I can't share any details at this moment.

BTW. What is missing to close this issue?

[BigRoy]

What is missing to close this issue?

Good question. Since it's more of a discussion or question as opposed to a bug or feature request (at this stage) I think seeing it clearly documented on how to approach the shading, e.g. procedurally.

However, with things being under such heavy development I'd be happy to close it to wait around. A "discussion" without a concrete answer might be more suited on a forum anyway.

I will close it now. Feel free to reopen if need arises.