Storing Maya Name and Namespace for round trips and heuristics

[dgovil]

Just starting a discussion since this has come up a few times. This might be a bit of a brain dump.

Given a Maya node foo:spam:my_pCube1, the resulting USD would be foo_spam_my_pCube1 where the namespaces are converted to an underscore delimited set of tokens. You can no longer tell what's a namespace or just part of the object name.

This makes it tricky on re-import to bring an object back into its original namespace, and also makes it tricky in a pipeline context to know what the object was originally called if that is somehow semantically useful information.

I think it would be useful for various future heuristics if the Maya USD export would write in the following information to the prims:

1. The prims namespace (if it exists)
2. The nodes display name (if it differs from the resulting prim name)

The reason I wanted to start this as a discussion is because:

1. I think it's important to know if people think that the idea holds weight or not
2. Discussing the implication of potentially storing all this extra data into the USD file
3. How best to store this efficiently?
4. What gates should there be to enable/disable this behaviour if it's not desirable?

So in order:

Does this idea of storing name and namespace make sense?

I think it would be beneficial for any pipelines that want to have ways to consistently deal with objects even after they're renamed. e.g even reimporting something back into Maya, this would help if you knew what namespace something was under originally.

Implications of storing all this data?

This could potentially make the USD file larger by adding around 2 new attributes per prim.
Some ideas to mitigate this are (if mitigation is desirable):

1. if you consider foo_spam_my_pCube1 to actually be two pieces foo_spam and my_pCube1, then you only need to write the name attribute if the latter is different than the maya name. in this case my_pCube1 is also the name of the maya node so we don't need to write the node name, but if it were written as foo_spam_my_pCube2 then we'd write the name into as an attribute.

2. For the namespace, we could store it on every prim, or we could store it only when the Maya objects namespace differs from its parents namespace.

3. We could record namespaces as Scope prims that any member nodes are stored under. e.g. foo:spam:my_pCube1 would become the following. However I think this might be the most disruptive to workflows. I am also unclear if transforms can pass transitively through a Scope prim, since it's not xformable itself. However it does nicely separate concerns.

def Scope "foo" {
    def Scope "spam" {
        def Mesh "my_pCube1" {}
    }
}

How best to store this efficiently.

Object Name

For Object names, I think it's best to just store it as a string on since it's unlikely to be shared by multiple objects.
I don't think USD has a displayName property for Prims, but I would think it could be worth recommending as an addition to the USD spec. That would let many different DCCs share a single utf-8 compatible name, especially since prim names do not allow for utf-8 (so non ascii names are lossy today).
Short of that addition, I think a namespaced Maya:displayName would make sense, so if that attribute is every standardized, it's easy to be compliant.

Namespace

There are more implications for namespaces since many prims may share them depending how often they're represented:

1. Store the namespace as a single TfToken attribute: eg Token Maya:namespace = foo:spam. Many objects share their namespaces so it's efficient to store as a token.
2. Store the namespace as a TfToken array: eg Token[] Maya:namespace = [foo, spam]. This would allow even more sharing of tokens, though might require more work to join/split the namespacing.
3. Store namespaces as scopes as above. I think this might be disruptive potentially but has the benefit that things are pretty clean to look at. It does cause the issue that non Namespace scopes can get misconstrued as a Namespace. So perhaps we'd also would need an identifying attribute.
4. Create a hierarchy of scopes/references elsewhere, and use rels to link to them. e.g.

def Scope "foo" {
    def Scope "spam" {}
}

def Mesh "my_pCube1" {
    rel Maya:namespace = </foo/spam>
}

Personally I lean towards option 2, but these are just what came up during brainstorming with @ysiewappl

Gating this data

This new data might not be desirable. e.g if someone wanted to optimize for space perhaps.

Some options could be:

1. They write a chaser to clean up after
2. Gate it behind an environment variable to disable it
3. Gate it behind a flag. (I know there's a desire to keep flag count low...so I have a proposal for an -optimizations flag, with multiple arguments to allow for setting options for optimization for a given flag, so multiple optimizations could be grouped together)
4. It isn't that big a deal for the near term so table the optimizations till a later date when it does start causing concern.

---

Anyway this is the end of my braindump. Would love to hear peoples thoughts.