Variants do not preserve order
dgovil opened this issue · comments
Description of Issue
For pipeline purposes, it would be very useful to be able to preserve variant ordering within a USD file. This is especially important when presenting the variants to artists etc in a UI.
Currently (USD 24.5), if you author variants in a given order, they will be stored in an implementation defined way. This appears to be alphabetical, but I do not see this as an expressly determined logic, so it may be non-deterministic depending on the underlying data structures behaviour.
This can be worked around somewhat by use of custom pipeline metadata but requires every application to specify the same logic. This also doesn't scale to third party vendors or creators easily.
This issue happens for both crate files and text files, where ordering isn't preserved.
It would be great if there was a way to specify variant ordering in a way such that USD's methods to query the Variant names just return them in a pre-determined order. It might also be useful to store them in authoring order by default.
Steps to Reproduce
Run this code and open the file. Writing to Crate as well will show the issue if query back the variants.
from pxr import Usd, UsdGeom
stage = Usd.Stage.CreateNew('planets.usda')
xform = UsdGeom.Xform.Define(stage, '/planets')
prim = xform.GetPrim()
vset = prim.GetVariantSets().AddVariantSet("Planets")
for planet in ["Mercury", "Venus", "Earth", "Mars", "Jupiter", "Saturn", "Uranus"]:
vset.AddVariant(planet)
vset.SetVariantSelection(planet)
stage.Save()
Hi Dhruv. I know that the text file format tries to store prims and properties in a deterministic way to make diffing easier. I suspect it does something similar for variants.
Prims and properties use these fields to create user defined orderings.
https://github.com/PixarAnimationStudios/OpenUSD/blob/release/pxr/usd/sdf/schema.cpp#L880
https://github.com/PixarAnimationStudios/OpenUSD/blob/release/pxr/usd/sdf/schema.cpp#L882
@tylerm-nv and @nvidia-jomiller are currently working on a proposal to allow variant sets have their own metadata. I think we could add a variantOrder field to our proposal that would allow for user ordering of variants.
Order gets lost when reading from a crate file as well. I tried authoring directly to a USDC but the data gets read back in out of order.
I'll amend my issue to make that clearer, because my example wrote to USDA for ease of reading.
If y'all are adding metadata to support ordering , that would be awesome. I think it would also be beneficial to order the variant sets themselves too if possible.
If y'all are adding metadata to support ordering , that would be awesome. I think it would also be beneficial to order the variant sets themselves too if possible.
This is a good question. I initially thought this made a lot of sense. However, variantSetNames is already a list op with ordering that affects the order of how variants compose. I'd raise whether or not a separate presentation ordering could potentially confuse users.
def my_prim(append variantSets = ["model", "material"] /* This order defines the composition ordering of variant sets*/ ) {
reorder variantSets = ["material", "model", "level_of_detail"] /* This order defines the presentation ordering of variant sets*/
}
I think it would be easy to incorporate into the proposal though, if there's consensus that there's enough of a need for two distinct orderings.
Ah you're right. Sorry I didn't think of that (brain still waking up this morning). Yeah since it's a list op , I think we're good for variant sets.
It's just the variants within them that would need some form of ordering control.
Filed as internal issue #USD-9662