Hello. I wanted to see if there’s ever been any thoughts about allowing metadata for Variant Sets. We’re able to set opinions like displayName, hidden, displayGroup, etc. on prim and property specs that are useful to customize a user interfaces but lack this feature for variant sets.
It makes sense to me that you can’t author this data on the variants themselves since all opinions are composed into the prim, but per sdf/schema.cpp variant set specs only have a single authorable field (variantChildren).
Hey Matt,
I haven’t dug far enough into the code to see where it’s actually prohibited (since SetInfo/GetInfo is on base SdfSpec), but if it doesn’t actually parse, I suspect the reasoning is that, were we to allow it, we’d really actually need two V’s in LIVVRPS, for metadata, at least, and rationalize why VariantSet is stronger than Variant, or vice-versa.
Relatedly, just to clarify, you can author metadata to Variants themselves… there’s just no USD-level API for retrieving it (guessing you were thinking about on UsdVariantSet?), other than inspecting UsdPrimStacks or UsdPrimCompositionQuery’s.
Agreed that there’s not anything in SdfSchema that prevents this. I think the main blocker would be there’s no place in the text file format to serialize those opinions.
To clarify, the suggestion is that there’s a place to author opinions about the variant sets themselves.
For a more concrete motivating example–
def "my_prim" (append variantSets = "__my_hidden_variant") {
variantSet "__my_hidden_variant" (hidden=True /* this does not currently work*/) = {
"variant1" {}
"variant2" {}
}
}
def GetUnhiddenVariantSets(prim):
"""present all variant sets with `hidden=false` in a user interface"""
variantSets = prim.GetVariantSets()
for variantSetName in variantSets.GetNames():
if not (variantSet := variantSets.GetVariantSet(variantSetName)).GetMetadata('hidden'):
yield variantSet
We’ll give it a think… it’d need to be more like a PropertySpec in that you would not be able to put composition metadata, or other kinds of prim metadata (like active, instanceable) on it… it’s really usefully limited only to GUI/doc kinds of things, yes?
PropertySpec is a good analogy for what we were thinking. This would primarily benefit UIs that want to display information about the variants and variant sets.
After a team discussion, we agree this makes sense, @nvmkuruc , and have the following notes:
The parser and text writer will need to be updated (along with SdfSchema), though we believe if you were able to author it, it would serialize/deserialize properly from crate already
It’s going to require custom resolve logic that will likely want to be factored into variantSets.cpp
UsdVariantSets is not a UsdObject, and we don’t think it should be (because it’s not something you visit while traversing a scene), which, though, means it will need to provide its own API for metadata access
Thanks for the consideration! We’re going to continue to discuss this more internally and hopefully put together a proposal.
UsdVariantSets is not a UsdObject, and we don’t think it should be (because it’s not something you visit while traversing a scene), which, though, means it will need to provide its own API for metadata access
I don’t necessarily feel strongly that a UsdVariantSet should be a UsdObject, but I did want to explore the idea a little bit more, specifically the comment about variant sets not being traversed. Prims are generally traversed in the stage, but broad property traversals are usually for the purposes of user interfaces or validation. (Schemas are the preferred method for interfacing with properties.) It seems like a UsdVariantSets would function similarly as properties, leaf level “objects” with any traversal being used for user interfaces and validation. It could be desirable to retrieve a UsdVariantSet via GetObjectAtPath.
The drawbacks I see about making UsdVariantSet derive from UsdObject are
UsdObject provides an assetInfo dictionary interface which seems like it wouldn’t ever apply to UsdVariantSets
Ambiguity with path expressions, relationships, and collections as they’d be objects that aren’t targetable
(For clarity, instances of UsdVariantSets, I definitely wouldn’t expect to be an object).
