PixarAnimationStudios
UsdAbc: translate the property's arrayExtent metadata into elementSize
Description of Change(s)
For the example file in the referenced bug report, the Alembic property has the metadata arrayExtent: 3, podExtent: 1, podName: float32_t.
This was translated into a float[] array with too many elements since the arrayExtent was ignored. This metadata seems to have an equivalent meaning to USD's elementSize, describing a grouping of consecutive elements in the array.
Houdini's Alembic exporter, for example, uses this in the generic case for translating float tuple attributes (which might have an arbitrary tuple size) if they're not a standard type like positions or colors.
(Note that if the property instead had metadata arrayExtent:1, podExtent:3, this behaved correctly as-is and would translate into a float3[] array)
Link to proposal (if applicable)
N/A
Fixes Issue(s)
Fixes: #3362
Checklist
-
[x] I have created this PR based on the dev branch
-
[x] I have followed the coding conventions
-
[x] I have added unit tests that exercise this functionality (Reference: testing guidelines)
-
[x] I have verified that all unit tests pass with the proposed changes
-
[x] I have submitted a signed Contributor License Agreement (Reference: Contributor License Agreement instructions)
@cameronwhite , while I can't be sure, it seems like arrayExtent is more general than just primvars in alembic? Last year we introduced arraySizeConstraint metadata for general array types in USD, and would like to promote it as preferred over elementSize (since it is also more expressive).
Could we ask that when reading in Alembic, you also add arraySizeConstraint to the attribute spec, and when writing from USD to alembic, check for that first and translate it to arrayExtent if present?
