Layer displayName

Community USD
1

Hello,
currently a layer’s display name is deduced from its identifier.
We are using URIs of the form:
uriIdentifier:some/path?asset=myAsset&version=myVersion#remapping=/path/to/local/data
So, since the displayName is deduced from the last ‘/’, we are ending up with “data” is display name which is of course not what we want.
If I understand correctly, there is no other way to define displayNames for layers, so we’d end up apprending something like:
#displayName=/MyLayerName
to the URI. This does the trick but seems very hacky and brittle wrt changes in how the internal GetDisplayName function works.
I’d like to ask if somebody has found a more clever solution and/or if there are plans to support another mechanism for layer displayNames ?
Thanks!
Marcel

2

This is an interesting question @mreinhard. (Note that even without query and fragments, you can end up with ambiguous display names. Consider-- /path/to/AssetA/geo.usd and /path/to/AssetB/geo.usd).

Currently, GetLayerDisplayName specializes “package” paths (ie. usdz).

You could imagine extending this to capture the query and fragment components of a URI as well-- so uri:/path/to/environment?variation=preview#north/side displays as environment?variation=preview#north/side.

If you want greater configurability (for example, if you wanted only query or only fragment included), you could imagine shifting some of this logic out of sdf and into Ar so resolver plugins can provide their own short or display names of assets.

I suspect that encoding a user defined display name in the layer isn’t ideal, because it would require opening and extracting the metadata.

3

Largely agree with what @nvmkuruc is proposing… the only hardcoded logic that should be in Sdf, I think, is the package-relative identifier logic. Everything else should be delegated to the resolver (especially hunting for "/"s). I don’t know if it should (or can) be the resolver’s job to ensure all display names are unique if the source identifiers are - at least I don’t think resolver can in a way that is stable run to run).

An interesting question is whether the concept of splitting identifiers and displayNames into “asset + asset/query/load parameters” is one we should be canonizing? If query params are important, so too should SDF_FILE_FORMAT_ARGUMENTS, no? They both potentially affect a layer’s contents.

4

Yes, I think that even from my example, you can see that the logic of what an artist should see in the displayName is highly dependent on the URI scheme and pipeline considerations.
I am honestly less worried about ambiguity then just showing something sensible at the moment.
Given that, I think it is a great idea to have the resolver provide the display name, as the URI logic is in their anyways and it provides the possibility of easily defining that on the studio level.

5

Would you file an Issue for it, Marcel?

6

Absolutely, here it is:

Thanks a lot to both of you!