I've been building all of the assets for what will be a pretty heavy scene, asset wise.

So far, so good... time to 1st pixel with XPU is about 2 seconds on a pretty decent machine. This same setup in OBJ made redshift fall over, even with making all of the geo RS proxies.

But I'm about to start adding more hero / complex / simulations / animations and want to be sure I'm going about this right.

1. Load all of the geo. I've got almost everything that isn't a sim built and textured and loaded as a reference. (handy hint here: if you texture in Substance Painter it does a great job of spitting out USD files that are ready to reference)

2. I have some textures that are animated and shared across several of the references, and Solaris doesn't seem to like using time based textures in the references, so I used an edit material properties and replaced the textures with /geo/*/newMaterial.$F.png and that worked pretty well.

3. Any additional texture assignments in the mat lib, and a camera lens shader

4. Lights

5. Cameras

6. Render settings

7. USD Render Rop


So before I get crazy with the really heavy elements:

Should I be using bog standard merge nodes for all of the geometry? Each ref has a proper entry in the tree, and that will continue.

I've got the geo broken out by LOD here. Hero, close, medium and far. (thus the 4 different clusters / merges)

While creating most of the USD references I have now directly out of Substance is fast and convenient, these files are not created with payload info. Is there a way to add that in Solaris after the fact?

The following URLs are suuuuper helpful and deep, and I'm posting here so that anyone looking for similar solutions can dig through these as well:

https://www.sidefx.com/docs/houdini/solaris/performance.html [www.sidefx.com]

https://lucascheller.github.io/VFX-UsdSurvivalGuide/index.html [lucascheller.github.io]

But I'm also asking here to see what the folks that have much more technical knowledge that I (pretty much all of you) might be able to give some quick advice on pitfalls and other things you've come across that might be helpful.

thanks!

2. The Material Library LOP will author time-varying attributes on shaders, but you have to explicitly enable "Allow Shader Parameter Animation" on the Material Library LOP. The way you described with a Material Library followed by an Edit Material Properties LOP is going to be much faster to cook because it doesn't require regenerating the material from the VOP network on every frame - just running the edit materials property LOP to set one attribute on the otherwise-unchanging material prims.

Merges are fine for combining a bunch of References into a single scene graph, but I'd suggest using the Flatten Layers Merge Style so you don't end up with a separate sublayer for bringing in each referenced asset. The other option is to just chain the Reference LOPs together. The end result will be the same and the performance will be very similar, so it's really a question of how you want to build and lay out your network. You can also mix and match with some chaining and some Merges.

Solaris has the Loft Payload Info LOP for adding extent information to any primitive with a payload specified on it. If you are payloading in your substance assets, this LOP should let you see bounding boxes for the assets when you unload the payloads. I assume this is the behavior you're interested in?

Thanks for this!

Glad that the way I'm approaching a bigger scene is seemingly working.

I'll have to dig into the Loft Payload LOP. I'm currently bringing in USD files as references, and I can't seem to sort out any way to unload the payloads in my current workflow...

Sorry if this is a silly question, but you know references and payloads are very specific and separate things, right? The Refrence LOP lets you choose whether to "reference" the file on disk or "payload" the file on disk. If you are "referencing" the files on disk then you have no payloads in your scene, so "unloading payloads" won't do anything. Unless the files you are referencing into your scene have payloads inside them. In which case I'm not sure why you'd be having trouble unloading them...

Not a silly question at all... I'm an absolute noob with USD, so still trying to figure things out and I have no shame in being told "you're doing it wrong".

I'm using the asset reference node to load in my usd assets.

This is probably a me issue, and I'm likely using the wrong method to do this.

My files were not built with payloads (yes, i should have but its too late now), and i absolutely understand that will prevent me from unloading them.

I guess I could reframe my question as "can i add / create the payloads" once the assets have been loaded into the scene?

Which in itself is probably a stupid question, lol, but I'm just not sure.

thanks again for your responses, they are absolutely helpful.

I'm using the asset reference node to load in my usd assets.

That's normally just fine, though it only allows for referencing; the vanilla reference lop can switch to 'payload file' mode. But you'd need to move your transforms to a separate Transform LOP.

If you aren't able to re-export your USD assets using the Component Builder, you could unlock each of the Asset Reference nodes, and on the Reference LOP inside, switch the type over to 'payload file' instead of 'reference file'; then insert a Loft Payload Info that @mtucker mentioned, between the align_to_up_axis and OUT nodes. Set the primitives to `chs("../primpath")`and that should help your scene to be more un-loadable.

This suggestion may or may not work, there might be details we can't see.

I guess I could reframe my question as "can i add / create the payloads" once the assets have been loaded into the scene?

Unfortunately, no there isn't really a way to do that, it needs to exist in the first place. Take a look at the Component Builder, it might not be as much work as you're expecting, to re-export your assets so you have proper payloads; but if not hopefully these suggestions help get you going.

I'll confess that after several years of reading about Solaris and USD, I still don't understand what a payload is. I consider myself reasonably intelligent, but the abstractness of this seems to be beyond my intellect.

An "explain it to me like I'm 5" with pictures and a boatload of hand-holding would be very welcome as the next SideFX YouTube video. To be perfectly honest, an "explain it to me like I'm a mentally-challenged country bumpkin, who has been living under a rock for the last 30 years" would be even better. Sorry for derailing this thread.

eikonoklastes
I still don't understand what a payload is

I use a mental model where I think of a payload as "a box of stuff". You don't always need to know what's in the box, which means you don't need to allocate any accounting (computer RAM etc) to the contents ... it's just a mystery box (likely with a known size) at this point. Eventually you probably care about what's inside (very likely when doing a final render for example), so at that point you open the box and now you've got all the contents (a beautiful tree model with millions and millions of polygons for example) and can pay the price for them.

https://www.sidefx.com/docs/houdini/solaris/usd.html#:~:text=A%20payload%20is%20essentially%20a,a%20scene%20you%20care%20about.
https://openusd.org/release/maxperf.html#package-assets-with-payloads [openusd.org]

I would urge caution in extending that mental model to "ah, so it's just like using a bounding box as a proxy". While it's true that use of the Proxy Purpose can extend similar memory/accounting savings to the *consumer* of a Stage (your viewport for example), ultimately USD as a core *manager* of the Stage still ends up having to deal with a lot of the non-proxy data as well.

That's how I make peace with this at least

goldleaf
If you aren't able to re-export your USD assets using the Component Builder, you could unlock each of the Asset Reference nodes, and on the Reference LOP inside, switch the type over to 'payload file' instead of 'reference file'; then insert a Loft Payload Info that @mtucker mentioned, between the align_to_up_axis and OUT nodes. Set the primitives to `chs("../primpath")`and that should help your scene to be more un-loadable.

Thanks for this I'll give this a go!

I was on a bit of a nutty deadline and did the thing that we all do: come up with a panicky solution that does the job.

In my case, I have several big groups of assets that all funnel through their own single merge node, all merged into one big geo tree. So right after each big merge, i just put a switch between the merge node and an empty null. Then I made a control null with it's own little system of checkboxes to control the switches, because the group editor thing (shift+z) doesn't work on the stage like it does in obj.

Hi,

To follow up on this thread. We have assets that are composed of many individual .usd and .usda files.

I have attached a simple example here of a simplified asset:



Is there a best practice where to use payloads vs reference?

Say I need to instance this tree 10,000 times in a complex forest scene. Would it be recommended to set all the above .usda files to be payload? Only geometry needs to be payloaded? What about materials?

Thanks