I have an alembic file that contains multiple meshes in a hierarchy. If I load this abc file using Payload, I get the hierarchy in my scenegraph as expected, and I can load/unload the overall asset. Let's say I uncheck “Load all payloads” in the Scenegraph options. If I expand the hierarchy a bit and want to load only part of the alembic, say one mesh or two, I can do so, but then the entire hierarchy becomes visible in the viewport. Now, I still have “Populate all primitives” enabled in my SG settings, but if the rest of my prims are unloaded, as the Scenegraph tells me they are, why am I seeing them in the viewport? Doesn't seeing them in the viewport imply that they are actually loaded?

(coming from Katana here, which has different paradigms for expansion vs viewport drawing, so just looking for some education…)

And a follow-up question actually… is bounding box representation only for “loaded” payload prims or can I draw bounding boxes for unloaded payloads as well (again, coming from Katana…)?

one alembic = one payload = one unloaded prim

Loading the alembic payload will load the entire file. There's no way to only load part of it, unless each location in the alembic hierarchy was a separate payload.

I think unloaded payloads can only draw bounding boxes if the payload prim has extents hint authored.

Makes sense! Thanks!

Looking into it further, it Populate primitives can be used to disable individual primitives from an alembic hierarchy.

I also couldn't get the extents hints to affect the bbox draw mode. I get nothing with the prim unloaded/unpopulated.

Populate primitives can be used for finer-grain control of which parts to load, but it's a little harder to control because you have to provide a _complete_ list of the things that should load. So if you add a new branch to your scene, you need to update your populate list (even if it doesn't contain any payloads). May or may not be a big deal depending onthe complexity of your scene.

The drawing of bounding boxes for unloaded payloads is a feature that was introduced in USD 20.05, and so will be available in the next major release of Houdini. But it is not, and will not, be available in 18.0.

That actually goes into another area I was confused about: Populate Primitives. From reading the docs it sounded like it only affected viewport drawing, not actual load state. In the case of payloads, it sounds like it's potentially two different flags that we might need to manage?

I'll also shamelessly admit right here that I'm a bit overwhelmed by having potentially 4 different flags available which all manage a prim's “presence” state: Populated, Loaded, Active, Visible. I know what they do (barring the whole populated thing), but the overlap does get a little confusing.

Good to hear that about the future, Mark!

It's not just that there are four ways of doing it, each of those four ways can be applied to the viewport only (by making changes in the scene graph tree) or applied in the LOP Network (using the Configure Stage node for payload loading and stage population, and Prune for visibility and activation). Why so many choices? Because USD has all these options and one of our main goals with LOPs is to faithfully present the capabilities of USD. I think each one has a use (descending order of both complexity to use and performance benefit):

1. Stage population mask is the scariest and most error prone, but there's nothing like it's performance when you're _sure_ you only want to deal with a small subsection of your scene graph (only show me /world/house5/room6). It cuts out all composition costs and all hydra costs related to prims outside that branch. The downside is that it is an absolute block. You can't author stuff outside that branch. If your materials or lights are defined outside that branch, they don't show up either (unless you also add the locations for those prims to your population mask).

2. Payloads are my favorite. They are easy to understand as “delayed load” or “packed primitives”, especially in 18.5 where you can see their bounding boxes. They also completely prevent all composition and hydra costs associated with unloaded data. But they require you to set up ahead of time where the payloading happens. Fortunately, the answer is almost always “at the level of an asset”. You still pay some cost to compose the ancestor prims of the assets even when a payload is unloaded, but USD is pretty fast, so that's not something to be worried about unless your scene is enormous (millions and millions of separate assets prims).

3. Activation is in many ways a lot like adhoc payloads. Perhaps even more so than the stage population mask. By deactivating a prim you are telling USD and hydra to ignore that prim completely. Sort of like if you unloaded the payload at that point, but without there needing to be a payload defined at that spot. Unlike payloads though, deactivation has to be a manual decision (or if you use a prune LOP, at least a procedural decision). With payloads you start by saying “load nothing except what I tell you”. With activation you have to load everything, then deactivate the things you don't want. I suppose if you build your pipeline around a deactivation workflow instead of a payloading workflow, you could fairly easily mark specific points in your scene graph as “deactivate here” points (similar to how payloads indicate “unload here”), and then have Prune LOP presets to find and deactivate those prims… Anyway, I think I've gone into the weeds a bit here. Like payload and population masking, stuff under a deactivate prim becomes inaccessible for editing.

4. Visibility is safe and simple. It _only_ has meaning to the viewport/hydra, whether you set it in the LOP network or the scene graph tree. It saves nothing in terms of composition costs (which is its downside), but lets you choose what parts to actually render (which is usually the most expensive part, and really the only thing you need to worry about until your scene get very large and complex). When you make prims invisible, the prim and its children are all still “there” in the composition sense, and can be inspected, referenced, and manipulated exactly like visible prims.

Anyway, that's my take on these four options and how they compare. I'd be curious to hear how others think of them…

Anyway, that's my take on these four options and how they compare. I'd be curious to hear how others think of them…

I can't offer my opinion on the different approaches, but I can say thank you for making this list in which you have this ‘breakdown’ of different approaches.

It helps me consider and research different approaches to take compared to my current way.

Thanks, Mark! That's a great explanation of the differences and I would definitely file that under “Demystifying the Scenegraph”. Might make a useful addendum to the docs.

Apart from my confusion on Population masks, these are essentially how I understood these flags to work too. Payloads are an obvious win, and once we get bounding box representation for unloaded prims it will help a lot in practice. Deactivation/Pruning is my basic optimization tool as well. Trim the graph down to just what you need and prevent the rest from even being acknowledged.

But I will clearly need to get more familiar with Population masking.

Thanks again for posting this!

Hi guys, I've a question about it.
Can I save this loading/unloading information in usd file? Or this option remain valid only in file viewport?

My goal would to load initially in stage only part of a set that I need to work!
thakyou

mrcbersani
Hi guys, I've a question about it.
Can I save this loading/unloading information in usd file? Or this option remain valid only in file viewport?

No the load/unload state can't be saved in the usd file. It gets saved as part of the lop network and can be controlled from the Scene Graph Tree toolbar. [www.sidefx.com]

thankyou guys