Hey,

I'm trying to get my head around dealing with heavy assets in USD, which it seems, could be handled with Payloads - but it's not clear to me how this will work in real world usage:

For example, say i'm trying to assemble a house asset. It has some walls and a roof which is quite light. However it also has a lot of roof tiles (which are a separate USD file saved through the import LOP save path). These tiles are heavy, and not necessary to see in the viewport, they only really need to be seen at render time, or in specific cases. I'm using a reference LOP to nest the tiles under /house/roof/ and set it to payload.

= Payloads are loaded by default as references - from what I can tell this default is only override by the “Load Masks” options - but how does this help with an asset which is passed between various departments and artists? If the artist doesn't know the exact contents of the asset they're loading, how are they meant to know to turn turn off “Load all payloads” before loading the asset in? (once they're loading said heavy asset in, it's too late). Is the answer to just force it with an env variable?

= Payload “load control” per asset - From what I understand this is just a blanket option, but what if an artists wants to “just load in **this** payload but not the other assets'”. This again seems like it's not so helpful?

Am I simply misunderstanding the concept of payloads here? What would be a recommended workflow to achieve what i'm after? Ideally handling all this within the USD structure would be the way to go…

You're not misunderstanding the concept but manually managing the load state of many references definitely places a burden on the user. There's arguably other features that will work better for your roof tile scenario.

Purpose is the main one that springs to mind:

https://graphics.pixar.com/usd/docs/api/usd_geom_page_front.html#UsdGeom_ImageablePurpose [graphics.pixar.com]

Purpose can be authored via an editproperties lop.

Alternatively, variants also work well for this kind of thing. Unlike purpose, variants won't switch automatically between preview and final renders. But they are more powerful/flexible since you can author whatever changes you want such as multiple LOD's. There's a createlod lop that might be useful.


–ant

Thanks for the suggestion ant!

Purpose seems like it will do the job after a quick read of the page you linked, although the way it reads, it sounds as if it's a sort of tag, which requires the pipeline to action upon in order to take advantage of this? I'm a bit unsure of whether this is something that will just work out of the box (a quick try just then didn't seem to do anything obvious like “hiding” the geo in the viewport).

I'm very interested to know whether anyone else has played with this and had success…

Variants are definitely not what i'm after - the point is to have a no brainer setup so that once it's done, it just works for anyone that picks the asset up without a chance of forgetting to flip the switch before render. Think similar to a fur procedural - you only see bounds in the viewport, and it's expanded at render time.

Cheers!

Purpose seems to work for me using HoudiniGL and Karma. Attached is a simple scene using purpose - for me Karma renders a sphere while HoudiniGL renders a cube.

In general I would expect all delegates to support purpose since it's a core function of UsdGeom

–ant

Great thanks! My brain wasn't really thinking in USD when I tried it before, so your example gave it a bit of a kick. I was able to replicate that and get it to work.

However there is definitely something buggy about this being evaluated (at least in 18.416) - jumping between different geo or spots in the LOPS tree seem to break it and the “render” geo ends up being loaded in / visible in viewport, even though it's clearly still got the render purpose on it… Takes a bit of messing around to get it to turn the geo off again.

I've just resigned myself to using the “Draw Mode: Bounding Box” instead which is way simpler to set, and does the job I need, which is keep the viewport responsive, although i'm guessing it's not as efficient as using payloads or setting the purpose to render. I can see the potential of purposes when you want some proxy geo more complex than a cube of the bounds, or if you have some very very dense section of the USD that you don't want to load in to memory until absolutely necessary.

sprogsurfer
However there is definitely something buggy about this being evaluated (at least in 18.416)

Yes in 18.0.460 when bouncing between lops I have to toggle the viewport setting for render off, on and then back off to get the viewport to not draw the render geom.

sprogsurfer
I've just resigned myself to using the “Draw Mode: Bounding Box”

The main catch with draw mode is that it's a model-only mechanism. If all of your model geometry is render only then it will work. But if your model contains a mix of render only geometry and “regular” geometry that you want drawing in all contexts you can't use draw mode for that.

sprogsurfer
if you have some very very dense section of the USD that you don't want to load in to memory until absolutely necessary.

Yes payloads and variants can both help there if you have a ton of prims (i.e thousands or tens of thousands) where you want to avoid composition costs. But if its a small number of prims with heavy geo purpose and/or draw mode work well. There's typically very little cost to heavy attribute data on a prim that doesn't get rendered.