Hello, i am working on a project where i am instancing a single variable asset on a lot of points from SOPS. I need the instancer LOP to randomly pick a variant from an asset per point, but to still maintain the reference to the original variable asset that i reference as the prototype.

In order to get the point instancer to pick a random variant in the past, i have used the explore variants LOP, but this seems to break the link to the original USD that i was referencing if i try to export the "instancing setup", presumably because the explore variants LOP is creating a copy per variant and not directly using the original asset?

If i forego the explore variants lop and just plug the reference node directly into the instancer, the resulting exported USD maintains the reference to the asset USD file, and i also dont get the
"Error: Layer saved to a location generated from a node path:..." error that i have seen a lot before deciding to make this post. The only problem with this solution is of course that the instancer just instances the default variant, and i can't seem to get it to pick variants at random.

So how do i create/export an instancing setup that maintains a clear reference to the asset being instanced (so i can make changes to it later if needed, for example) while still picking random variants per instance point?

PS. in a later update would it not make sense to just have som sort of "pick random variant" toggle on the instancer LOP? It would do wonders for the workflow imo.

thx.

The explorebvariants lop adds some additional composition structure that gets in the way of using the result with the instancer lop. It's possible to add all variants of an asset using a foreach loop though, and I think that results in the regular "asset reference" structure you're looking for.

What's the issue that you think Explore Variants doesn't work with the Instancer LOP?

The attached hip file demonstrates these two nodes working together. If you can alter this hip file in a way that makes this workflow stop working, please attach a modified version of the file so I can take a look. Thanks!

antc
The explorebvariants lop adds some additional composition structure that gets in the way of using the result with the instancer lop. It's possible to add all variants of an asset using a foreach loop though, and I think that results in the regular "asset reference" structure you're looking for.

Thank you so much, this seems to do what i wanted!

mtucker
What's the issue that you think Explore Variants doesn't work with the Instancer LOP?

The attached hip file demonstrates these two nodes working together. If you can alter this hip file in a way that makes this workflow stop working, please attach a modified version of the file so I can take a look. Thanks!

It makes the structure of the usd file weird if exported, so yes it works if you are just instancing in the one scene, but if you need to export the instancing setup to usd it adds a weird structure of folders i.e. ".../stage/yourStuff/reference.usd" which seems conveluted and unnecessary when the other way just references cleanly, and it also broke some stuff i am trying to do, at least in my very new to usd experience. Also the hip file attached didn't work at all but that may be just on my end, i have used the method before as you set it up where it worked fine. But the for loop solution is great so all is well!

thx alot for the help both!

Hey Mark, so in 20.5.278 your file isn't working for me. What's happening is the assetreference lop pulls in the pig asset to /pig, the explorevariants lop creates a bunch of internal references to /pig scoped below /explorevariants1/pig , and then the instances lop utilizes /explorevariants1/pig/* from the second input as prototypes. However the instancer lop doesn't succesfully copy /pig from the second input which is the all-important source of the internal references.

The cleanest solution to this problem (which we've hit internally before and so took the foreach loop approach) imo is to beef up the asset reference lop. Under the Variants tab, "Variant Name" could be "Variant Names" and take a list of variants or "*" for all variants. It would then build out multiple prim references in the same way as the foreach loop approach. Because the assetreference lop knows when it is creating a reference to a file it doesn't need to go the internal reference route like exporevariants is kind of forced to do.

antc
However the instancer lop doesn't succesfully copy /pig from the second input

You can disable "Only Copy Specified Prototype Primitives" on the Instancer LOP to avoid this issue.

The ".../stage/yourStuff/reference.usd" layers mean that you are authoring data without explicitly telling Solaris where to save it. If this is going to happen, there should always be a warning in your LOP Network telling you that haven't specified a save path. Then you can insert a Configure Layer LOP to tell Solaris where to save the layer.

I don't think there is anything special about the Explore Variants LOP that makes this kind of issue more likely to happen. And it should always be possible to convince LOPs to organize/save your layers differently, but I can't give any specific advice without knowing what your LOP Network is currently doing or what you actually want the final output to disk to look like.

mtucker
The ".../stage/yourStuff/reference.usd" layers mean that you are authoring data without explicitly telling Solaris where to save it. If this is going to happen, there should always be a warning in your LOP Network telling you that haven't specified a save path. Then you can insert a Configure Layer LOP to tell Solaris where to save the layer.

I do get that but the data being authored is created for no apparent reason and by houdini, so i don't know where to set the save path?

mtucker
but I can't give any specific advice without knowing what your LOP Network is currently doing or what you actually want the final output to disk to look like.

I will try to be more thorough, my bad.

I am trying to instance the containers on a cargo ship. I have a container asset with variants, but may need to change the container in the future for some reason or another, so i need the instances to keep a direct reference to the asset, since they would need to propegate the changes.

When using the Explore-Variants-LOP-Method, the resulting .usd output looks like this:



And because of the auto generated file "reference.usd", which i can't seem to figure out how to set a savepath for, i get the error:


If i check the .usda i created i can see a reference to the "reference.usd" file in the stage folder, but i can't find a way to find out what the "reference" file is doing because it is not ascii. So while it may work (only sometimes in my experience), it doesn't seem like the best way, with (imo) unnecessary files and folders being created, more references than necessary (that can and will break at some point in a production), and a sort of black-box-ish feeling.

Now what i was looking for, and what the For-Loop method antc provided gave me, was just a single .usd (in this case .usda for checking) that contained a direct reference to the asset i was instancing and which variant to use, like this:




I hope this was more clear, and just for the record, the problem is solved, so all is good! I just hope that this could maybe be made less convoluted in a future update if you get what the problem is, and agree that it is at least convoluted if not a direct "problem".

To see the contents of a binary USD file, you can either run the `usdcat` command line tool on it to convert it to USDA, or you can load the layer into Solaris and inspect it with the Scene Graph Layers pans.

Given the name of the USD file, it should be getting created by the node /stage/container/reference... This node is inside the container subnet, and so I can't see what it's doing or why it might be authoring this standalone layer. But you could probably use a configure layer between the container LOP and the foreach LOP to set the save path. Or, I suspect the For Each LOP is set to the default "Flatten Layers" option for Combine Iterations? If you change this parameter to "Flatten Into First Input's Active Layer" then all the USD you are generating will end up in a single layer, which it sounds like is what you want here?

I never know how to respond to questions about "is this too many steps to get the result I want", because if you wanted a different result it would be fewer steps. And we don't have enough data to know which is the most common result to want (presumably we want to set our parm defaults such that the most commonly desired outcome is the default outcome).

In this particular case, if my above guesses are correct, changing the default "Combine Iterations" parameter value would have avoided this confusion, right? We'll have to give it some thought here and maybe reassess our guess about the most commonly desired result...