USDA semantic inconsistency with reorder rootPrims

Hi all,

TLDR In USDA, reorder rootPrims statements were accidently being allowed in prim specs when they should have only been allowed at the layer level. We’re anticipating removing this from the parser in a future release. reorder primChildren statements should be used to get the same functionality. This only affects USDA and no other file format.

We have detected an inconsistency in the way the current USDA parser handles reordering of root prims. Currently, the statement reorder rootPrims = [] is allowed within the definition of a prim spec, where reorder nameChildren = [] will perform the same semantic function. The intent of reorder rootPrims = [] was that the statement be isolated to the layer parsing context, not the prim parsing context. We wanted to share this with the community to ensure that there would be no issue in correcting the semantic intent of re-ordering root prims by removing the ability for it to be used inside of a prim spec definition. That is, today the following would parse:

#usda 1.0

def "World" {
  reorder rootPrims = ["Prim3", "Prim2", "Prim1"]
  def "Prim1" {
  }
  def "Prim2" {
  }
  def "Prim3" {
  }
}

The intent is that it be used at the layer context, e.g.:

#usda 1.0
reorder rootPrims = ["Prim3", "Prim2", "Prim1"]
def "Prim1" {
}
def "Prim2" {
}
def "Prim3" {
}

Note that it is not in a prim spec definition in the second case. This shouldn’t be an issue for almost everyone, but wanted to make sure by putting this out there, thanks!

(Also note that the same semantics can be achieved as in the first case with reorder nameChlidren as:

#usda 1.0

def "World" {
  reorder nameChildren = ["Prim3", "Prim2", "Prim1"]
  def "Prim1" {
  }
  def "Prim2" {
  }
  def "Prim3" {
  }
}

)

1 Like

Note that @eslavin 's first example, the one we want to eliminate, is not constructible using any OpenUSD API’s - you can only get it by hand-authoring. So hopefully the change being proposed should not affect any existing assets or software.