Hi alls,
I’m new in this forum, so it’s a first time! Hello USD wolrd
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 ?
We use the structure of your assetA over here, except we have multiple layers and save our geometry as usdc.
I never understood the advantage of the assetB structure.
F
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 !
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.
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!
