Hey! I’m new here, so hopefully i’m posting in the right place, and asking the right questions. Feel free to point me in the right direction if not!
I’ve been trying to get a handle of USD over the last few months, and am currently looking at assets.
Something i’ve been chewing on is how usd files are organised on disk.
It’s a little unclear for me whether there’s a general consensus (or even need) for usd files to be organised in a certain way, or whether it just comes down to a pipeline choice.
For example, reading around the different documentation online, there is sometimes a nested directory structure that is referred to when it comes to expressing a USD Asset on disk, and paths when sublayering or referencing are generally shown as being relative.
For example, here on the usd work group there is an asset structure guideline.
Are there any pros/cons when it comes to USD and structuring its files on disk in this nested format, or is this more of a recommendation for when packaging an asset to send external? I’m very interested to know what other people are doing…
That’s a very good question - not one that I’m the best to answer for, but I think this is a large part of the reason why those examples are that way.
However, using relative paths does have another benefit with regards to asset path resolving. As far as I know, relative paths allow bypassing Asset Resolver logic in some ways and hence may provide a way more optimal way to resolve complex hierarchies of USD files. But this may have to be confirmed or denied by others.
Relative (anchored) paths do generally bypass some of the resolving logic, because it leverages the already-resolved path of the layer that contains the reference. But I’d suggest to use them when the referenced file is naturally part of “the same bundle of stuff”. For example, in our pipeline, we publish/version assets mostly monolithically, so all of its USD layers get revved at the same time. (Not entirely true as assets can reference other assets). But to the point you initially had and then removed, if you are relying on the contents of your asset-paths to specify versioning (which is all the ArDefaultResolver provides you with), then agreed it would get gnarly.
Versioning is, I think, a key reason studios implement/customize their own resolver.
In the last pipeline I worked with, all paths were absolute. Everything worked fine. If we needed to send something to another vendor, we had a script to package things up with relative paths and filter out what we wanted.
In the current pipeline I’m working with, everything is relative. We don’t have any intentions of sharing any of our work files outside of our network, but it could be handy when we archive a project to put it on a different network mount later.
With relative paths, we end up with long ../../../../ chains in our paths. It’s honestly not much of a problem because we make sure to have all the info necessary to recognize a file in its filename. Just by looking at the name of a file, we can tell if it’s in a shot, a sequence or an asset, we can tell the type of file, which department created it, etc. This is especially useful since usdview and Solaris only display the name of files in their Layer Stack and Composition tabs.
in our pipeline, there are parts of what contributes to an asset/element/layout that is “shared” across shots, assets or even shows.
internally we usually track versions of individual things (textures, shaders, models, lookdev packages and bindings, etc), but others might have their own way of tracking this.
so internally, paths are all over the place, but the “export for client” approach is simplified because you can then “localize” the paths when and how it is required ( basically like @flord said ).
usd has a lot of useful utils to make this possible.
Thanks for all the replies on this! It’s super helpful to understand a little bit more about what people are doing with their structure.
From reading these responses it seems that although there’s a bit of a performance gain from using relative paths, it’s not necessarily important enough to inform how people are organising structure on disk (which is more just driven by pipeline needs).
I’ll also be looking a bit further into some of the usd tools for dealing with resolving asset paths at package time, thanks for the tip Paolo
