The Pixar Kitchen has components made from three files:
(1) asset.usda payloads the payload file
payload = @./CastIron_payload.usd@</CastIron>
(2) asset_payload.usda references the geo file (3) asset.geom.usdc
prepend references = @./CastIron.geom.usd@</CastIron>
I’m curious to understand the reason for three files as opposed to two. Or to put it another way, would there be any disadvantage to doing it with two files instead, like so?
(1) asset.usda payloads (2) asset.geom.usdc.
prepend payload = @./CastIron.geom.usd@</CastIron>
The asset structure demonstrated in the Kitchen was developed as we were rolling out USD in 2013/14, and hasn’t been modified much since. Back then,
payload was a singular arc for a prim… I don’t think we made it list-editable until 2017 or 2018. That’s relevant because in production assets we always have a shading layer (which itself has sublayers), and sometimes other layers (in future there will be rigging layers also). The “extra layer” in the asset structure gave us a place to combine the shading and geometry flexibly, while still keeping the unloaded assets minimal.
I think if we were to reboot our asset structure we’d definitely investigate a simpler structure like:
prepend payload = [ @./CastIron.rig.usd@,
Thanks so much @spiff that’s enlightening!
In case it’s helpful, there’s an annotated asset structure here-- Principles of Scalable Asset Structure in OpenUSD — Omniverse USD latest documentation (nvidia.com)
It notes that the intermediate layer can be beneficial if
subLayers are used and layer muting is desired for debugging.
Good point about layer muting, @nvmkuruc … thinking on it, I polled the team to verify that issuing composition errors when muting a layer targeted by a reference or payload was a judgment call that it was unintentional to do so. There’s no intrinsic reason it needs to be an error, and I think we might want to support muting referenced assets, or individual geom/shading layers within an asset regardless of how they are stitched into the whole?