Representing complex Maya attribute data in USD

[Rhinoceroscity]

Maya attributes can be represented as structures, arrays, or both. For example, you might have a compound attribute with a boolean, int, string and a position, which itself is compound and contains 3 doubles. This attribute may also be an array.

However, in our investigation with USD, it seems like there isn't much support for similar data representation. Only basic data types can be represented by arrays, so one of our ideas would be to create individual arrays in USD for each element of the compound attribute in Maya, although this feels like it could become a maintenance nightmare pretty quick.

We've also investigated using "relationship" attributes that can point to another prim (which can be a custom class) to represent this data, although this didn't pan out either.

So, my question, what is the standard practice for representing complex array+compound Maya data in USD? Is there a better way to do it that isn't just breaking out each element of the structure into its own array?

[kxl-adsk]

This is an excellent question...but it's also one that I do not have an answer for. There is lots of flexibility in what you can do with arrays and compounds and often discovering this structure is expensive. Not sure if USD would allow such a thing... would be great to get some input from usd-interest folks. Maybe @spiffmon can weigh in?

[spiffmon]

I'm not familiar enough with the Maya API to determine from MfnCompundAttribute whether or not you are truly defining a "custom type" in code that can then be instantiated in any asset that loads the plugin. Assuming that is the case, then I think the closest we can currently come in USD is a multi-apply schema which, with the work Corey Revilla landed for USD 22.03, allows one to "nest" multi-apply schemas to effectively create "compounds of simple and compound types", which can then be instantiated multiple times on any prim (it sounds like Maya compound attributes can only be applied once each to a node, but it's fine to not make use of multi-apply's multiplicity, and it is only multi-apply schemas that allow property namespace-nesting of "sub-compounds".

That makes for a nice formalization, but you are still left with a SOA's to manage, rather than the AOS you're looking for. But... schema code generation is driven by jinja templates, and though there might be some roadbumps, I think AD should be able to create their own multi-apply schema templates that, in addition to what Pixar's do, defines an actual (nested?) struct of the elemental data types with API for getting and setting compound values (at a particular time) that actually does the management of the arrays in the schema for you.

This is a suggestion that is only half-baked, but it could be a generally useful thing, if AD is willing to experiment and flesh it out. Note though, that this will still lack the Maya compound attribute to connect the compound as a whole to another compound-valued attribute. The only place a feature like that exists in USD is "vstructs" in Sdr for shader-to-shader connections, and only for renderers that support it, which currently may be only RenderMan.