Maya Hydra Delegate hook up

[Kevin (Kevin Rosso)]

Hi usd community, I’m here for your help.

While writing our new pipeline, we faced some problems with the maya-usd integration. We tried to switch to Bifrost, but other issues came up.

So I was thinking about writing our own usd/maya integration. That is, creating SdfLayers, saving them within the Maya scene and manage them on our own.

That’s pretty easy to do, the problem comes with the viewport rendering. Maya already has a Hydra delegate, so I supposed I could just hook up to it, but I’m finding very little documentation about it and nothing that really makes me think that this is possible.

Does any of you have a little more insight about it? If I create a SdfLayer, is there a way to make it visible to maya’s hydra delegate (maybe via UFE?) or do I need to write my own implementation?

[dlanier (David Lanier)]

Hi Kevin,
I am from the maya-hydra team where we develop the support for Hydra render delegates in a maya viewport. In case you don’t know it yet, you can retrieve the project on GitHub - Autodesk/maya-hydra: A Maya plugin that replaces the main Maya viewport with a Hydra viewer..
And I don’t see why having prims in a layer would prevent them to be rendered in a maya hydra delegate. As soon as the prims are visible, we use the UsdImagingStageSceneIndex to load any usd data and convert it to hydra.

What are the problems you originally faced with maya-usd ?

If there are issues that look like bugs, please log them on the maya-usd project : GitHub - Autodesk/maya-usd: A common USD (Universal Scene Description) plugin for Autodesk Maya , same for maya-hydra on the github web site.
There are many people from Autodesk reading these forums, so feel free to describe any problem with maya-usd, maya-hydra or Bifrost you have.
Regards,
David

[Kevin (Kevin Rosso)]

Thanks David for taking the time to reply.

As per maya-usd, our main issue is with the 2GB limit of anonymous layers included in the maya scene.

The other issue is the lack of an internal asset resolver for those anonymous layers. Since their allocation in memory changes every time a scene is reopened, the composition arcs break, and so we need to manage them in an unnecessarily complicate way just to resolve the path on our own. But since that’s actually solvable, it isn’t a priority issue for us.

As soon as the prims are visible

That’s the problem I’m facing. I’m creating an SdfLayer and the only way I found to show its content, for now, it’s to put it inside a stage created by maya-usd. I can’t find the hook to tell maya “hey, here’s a layer you should display”.

I opened the same discussion on the maya-usd github, since I don’t think that’s a subject for a git issue. But if you prefer we can move the discussion there.

[dlanier (David Lanier)]

Thanks for your reply. I see.

So, not sure if this is useful for you, but In maya hydra we have an API which is named Flow viewport API and it lets you add some hydra primitives directly to the viewport.
These prims are pure hydra primitives, in the sense they are neither a maya native geometry translated to hydra nor a usd stage primitives.
So if you need a way to add custom hydra primitives into a hydra delegate using maya hydra then, that’s the way.

We have a few code examples on how to use that API in maya hydra from :

Autodesk/maya-hydra/blob/dev/lib/mayaHydra/flowViewportAPIExamples/flowViewportAPILocator/mhFlowViewportAPILocator.cpp

And

Autodesk/maya-hydra/blob/dev/lib/mayaHydra/flowViewportAPIExamples/footPrintNode/mhFootPrintNode.cpp

The difference between the 2 examples is that the footprint node is the simplest and doesn’t deal with selection picking/highlighting in the viewport.

Regards,
David

[Kevin (Kevin Rosso)]

So from what I understand my plugin should handle the translation between USD, Maya and Maya Hydra primitives?

I suppose then that the maya-usd developers are doing the same to show the USD prims in the native maya viewport and in maya-hydra.

If this is the case, this might be too big of a hassle for us to develop right now. We might try to find a different approach for the moment and dive into it later.

[dlanier (David Lanier)]

Can you explain what you are trying to achieve in your plugin ? What does the end result should be ?

Regards,
David

[shawnolson]

We’d love to hear more about your workflow and pipeline setup to understand the needs around having such large anonymous layers. Generally, we don’t recommend using anonymous layers for large quantities of data. Instead, it’s recommended to put very heavy data like mesh data into separate payload files.

From our end, we’d prefer to help solve the issues you are having so that you aren’t required to build a custom solution. We do intend to improve interop between Maya USD and Bifrost, and a large focus for us internally is asset resolution. If you can help us understand the specific issues you have run into with Bifrost it might help us with some work we are planning to tackle.

[Kevin (Kevin Rosso)]

The base idea is simple: we need the artist to be able to see the result of the maya/usd conversion and to make edits if needed.

In our current pipeline the converted layer isn’t inserted in the layer stack, but we publish it right away. This way, the artist doesn’t have direct control over it, so it’s hard to take full advantage of usd features. Also, it’s hard for them to understand the relationship between the maya data and the opinions they’re authoring in usd.

In our next pipeline, still in development, after the conversion we are building the layer stack in the maya scene, so the artist can check whether their edits are correct and won’t destroy the usd composition, or if those changes will show correctly in the layer stack. They can then make the needed changes and go back and forth between maya and usd before publishing.

The problem is in managing those converted usd layers. We could write those to disk, but the problem comes with managing the different users and variants, linked to the correct maya file. There are high chances of error, both in overwriting files, deleting files, or keeping useless usd files. It could become a file hell and our company management asked us to avoid it

The best solution would be to keep the layer anonymous, without writing it anywhere until it’s published. The problem here is that with the 2GB limit, the converted layer could be truncated when the file is saved. We ask the user to save before publish, so it will will be truncated for sure. (The artists could potentially convert a whole creature with millions of vertices)

We then tried with Bifrost, but we’re having high performance issues when creating all the nodes needed to convert the hierarchy to bifrost nodes. To make it procedural we’d need some kind of data to be passed to bifrost (ideally a dictionary), but we can’t set dictionaries as maya attributes.

I’m currently investigating in converting some string to a bifrost object, so that could be our solution. But at the end, bifrost still is less performant then maya-usd in the conversion, because it keeps evaluating everything whenever there is a change in the original Maya data.

The other solution I had in mind was to save the converted layer as a pickled object inside the fileInfo data, so to bypass the 2GB limit. And then make the maya viewport or maya hydra read that layer and display it to the artist.
In that case, could I force your scene delegate to manage my object too?