Asset_structure_ref_variantSet_payloads

Community USD
1

Hi alls,
I’m new in this forum, so it’s a first time! Hello USD wolrd :slight_smile:

I’m building an asset structure right now and I’ve reach a point that question me around the idea that a good way to handle shot composition is to have all assets referenced in it and then use payloads inside the assets to load the actual renderable geometry or proxy. It would keep the composition of the shot itself simple (no problems of mixed priority with payloads and references) and also it may optimise the heaviness, has nothing could be loaded or only “edits” on unloaded payloads. That said, here are my 2 options:
I would tend to the first one AssetA_001, wich is my latest version, but I’ve seen assets looking more like AssetB_001, so have you any insights about these 2 options ?

image
image1610×596 13.4 KB

Thanks you alls!

2

We use the structure of your assetA over here, except we have multiple layers and save our geometry as usdc. :wink:
I never understood the advantage of the assetB structure.
F

3

Thanks you François for your answer!
Ok so I’m not alone to not really get the beneafits of the assetB structure, I thought that it could be an old USD version’s way connected to old usd constraints mayby … ?
I don’t know, I’m still curious… so for you assetA works well ?

And yes yes we have multiple layers too, this is a simplified view of the structure to focus on my doubt.
Downstream, inside the assetName_variation usda files, we have underlying “creators” layers / “departments” layers. In fact I’m willing to have only .usd extension with different encodings (usda usdc) depending of the need of readability we have for each kind of asset ententies, this way we have the ability of changing the encoding inside of .usd without breaking the paths linking inside the usd tree structure.

Anyways, If somebody use a kind of assetB structure, I would be interested to know about it and why it !

Thanks again François!

4

There’s one technical reason we developed the assetB structure, which is that until about six years ago, you could only have a single payload on a prim, so you could not construct assetA.

There’s a flexibility/scalability reason that we still go with assetB, though it is addressess a problem there are other solutions to, also. In our pipeline (and you can’t tell this from the simplified Kitchen_set demo asset), in our top-level “asset assembling” layer (payloads.usda in your assetB), we subLayer in the shading so that we can mute the shading layers without errors, while referencing in the geometry (so that it is strictly weaker than the shading, in order for the shading to always win in geometry (e.g. primvar) overrides even inside of shading variantSets). If the shading were sublyered instead directly into assetA.usda, it would always be present even when the asset has not been loaded. I’m not sure how often we make use of this in workflow, though, but there’s tooling around it that would require a good reason to update, etc.

5

Ahh, that’s a pretty clear good reason! At least a strong main reason that I understand totally.
I’m note shure to perfectly get what you said after, I still getting used to this.
I have, too, a structure by department inside the “model_default” and “model_broken” (not visible in the picture). Each models has a subLayered structure by departements (modeling, shading, etc ), I use the assetA.usda only as a “variator/selector” and handler of datas about the a&sset itself.
So I think, it matches also with waht you explained, I’ll go for assertA structure so, it seems more adapted nowdays…

So, thanks again, both of you, I think we’ll have occasions to talk again! and I have to say, I’m really happy to have joined the aousd boat!

6

Hey! Apologies to revive this post from it’s grave. I came across this while building a similar asset structure to the assetA stream. I was wondering if you had developed it and how it is working out so far.

I looked into some other structures as well for example -
Asset.usda (payloads) → payload.usda (sublayers geo, mtl and other department layers).

I was wondering what is the benefit of using this structure over prepending each geo and mtl into variants, essentially departments are the variant sets and all their contributions are variant sets.

The only benefit I could think of was layer muting, to debug, other than that I’m not sure.

For now I have something like this and I was wondering if this is a valid choice to make for the asset structure.

def Xform "Asset" (
    kind = "component"
    
    variants = {
        string geo = "default"
        string mtl = "default"
    }
    prepend variantSets = ["mtl", "geo"]
)
{
    variantSet "geo" = {
        "geo_var_01" (
            prepend payload = @geo_var_01.usd@
        ) {

        }
        "default" (
            prepend payload = @defalt_geo.usd@
        ) {

        }
    }
    variantSet "mtl" = {
        "default" (
            prepend payload = @default_surf.usd@
        ) {

        }
        "mtl_var_01" (
            prepend payload = @mtl_var_01.usd@
        ) {

        }
    }
}```
7

Seems perfectly reasonable as long as your material and Geo variations are independent of each other.

8

Hey! Thank you for your quick response! I was wondering what you exactly mean by independent of each other?
Do you mean that the materials shouldn’t be assigned to any geometry from the get go and just exported to disk? The later they can be assigned and switched around.
Thank you! :slightly_smiling_face:

9

By independent I meant that any material variant makes sense to use with any geometry variant, because you allow them to be independently selectable. If only certain material variations make sense for any given geometry variant, then you would instead nest the creation of the material variantSet inside each geometric variant.

10

That is exactly what I was stuck on from a few days now. Finding a solution if a specific geo requires specific mtl.
The nested variant approach sounds cool and makes sense. What if the geo is so different that at that point it’s worth making a separate asset and adding that asset as a “asset” variant for example, instead of adding in geo or mtl.
For example - you can have a Porsche asset with variants for different models of the car. But all those variant cars are separate assets.
For something small like model main and model damage, it makes sense to keep them encapsulated in one asset, but if the difference is big enough, that it needs its separate materials maybe. It might be worth making a separate asset and adding that as a variant I feel like.

11

What I have seen in a studio is to manually author the “asset variant” on the root prim with valid combinations. Say you have 3 modeling variants and 7 materials, and some materials only apply to the last modeling variant. Then someone can go in and author the asset variant that simply sets the modeling and material variants and does it with only the valid combinations. This way, artists in layout can only switch the asset variant and cannot make the wrong choice.

What we are doing (in a simple pipeline, for simple projects) is to author the material variants to set the right modeling variant. Artists in layout only have to choose the material variant and it picks the right modeling automatcially.

12

Hi Flord,

Thanks for your response! After giving it some thought, and with Spiff’s nested variant hint in mind, I ended up going with something similar to what you described, though sort of in reverse. The modellers can freely export all the geo variants they want, without worrying about nested variants.During lookdev, we create an “asset” variant set, where we prepend the payload the mtl under a specific variant in the geo variant set. This way, when the layout artist switches between geos, the correct material is automatically assigned.Really appreciate all the tips and pointers you shared, thanks again! ^^

1 Like