Initial Sparse Array Edits Proposal

[gitamohr]

Description of Proposal

This proposal introduces a new value type, VtArrayEdit that can sparsely edit weaker VtArray opinions by inserting, erasing, and overwriting elements via a simple editing language, and a general framework for handling sparse attribute value opinions of any type in USD, including time-varying opinions in time samples and value clips.

Sparse Array-Editing Attribute Overrides in OpenUSD

Contributing

• I agree to and accept the Supplemental Terms.

[meshula]

I am wondering about a general resize operation (which I don't think I spotted). I'm thinking of a case like wanting to always successfully set the 3rd element of an array to some value. The proposal says that excess elements are ignored, and so I imagine that if the 3rd element is beyond the end of the array, my value is an excess element. So then, I notice that insert and remove change an array size, so I could imagine first doing three insertions at the end of the array in order to force that the array is at least three long, and now my write will succeed. Was something like resize minimum 3 already considered? That would be less problematic than my hypothetical work around.

[marktucker]

For visibility, mentioning that I posted my feedback as issues on the repository (to enable threaded discussions):
Concerns about interpolation: gitamohr#2
Question about indexed primvars: gitamohr#3

[nvmkuruc]

Thanks Alex, this proposal was excellent to read. Array edits open up a lot of possibilities.

I do want to ask some questions about the set of ops and their usage. Specifically, because VtArrayEdit is described in terms of lists, could they be intentionally or accidently used to record construction history?

If tooling supports "sparse insertion", it's likely that that the user may repeat that action multiple times. An indecisive user may repeatedly insert / delete / insert / delete. Edits may require a repair or "consolidation" pass to clear out cruft. Reasoning about a list of edits may be challenging for users and tooling.

The use cases enumerated in the proposal include

• Modifying a subset of points in a mesh (ie. to add footsteps to a ground plane)
• Appending or deleting elements (ie. to add or remove instances from a point instancer)
• Modifying xformOpOrder (ie. to add corrective unit scale operation)

It wasn't clear to me that these required insertion. I'm wondering if "array edits" could be formulated more like SdfListOps. Instead of arbitrary insertion, provide two edit operations that allow concatenation on either side of an array. That would avoid the need for lists of insertions and simplify flows around inspecting and modifying "array edits". This formulation shouldn't impact replace or delete edit operations. Their indices can be specified to be pre-concatenation indices.

Example:

token[] xformOpOrder = {extendBack: ["xformOp:scale:metersToCentimeters"],
                        extendFront: ["xformOp:scale:centimetersBackToMeters"]}
point3f points = {write: {100 : (1.0, 2.0, 3.0), 102: (3.0, 4.0, 5.0) }}
int[] ids = {delete: [2, 40]}

I'm really excited by the array edits proposal, how well it describes its interaction with value resolution, and the prospect of additional value types like dictionaries. My hope is avoiding sequences of edits (in the spirit of list ops) minimizes some of the complexities in authoring and tooling (ie. "construction history") without impacting the proposed use cases.