deformation weights/indices to be stored as primvars

[carstenkolve]

currently the weights/indices for deformation are stored as custom attributes, instead store them as primvars that will be exposed via the VariationReader and need to be read from the primvars in the CrowdGenerator, this will make it easier to inspect / modifiy them as well as benefit of compression etc.

A drawback of putting this stuff into primvars is that there currently no really elegant way to support varying influence lengths (ie, one point driven by 2 influences, the next one by 8). What we'd eventually like to do is support varying array data for indices and weights per point, but we currently don't because we haven't come up with a good way to interpolate those.

Anyhow, we ended up with a convention that looks like this:

• split up the the weights into individual primvars of size 1
• the max amount of those individual primvars would be determined by the maximum influence we have across the topology
• use a naming/number convention to identify which weight belongs to which influence
• expose those names as parameters on the nodes (with sensible defaults)
• convention looks like so: [nameOfInfluence]# [nameOfWeight]#
• so in a situation where you have a max of 3 influences, you'd have something that would look like: influenceJointId_0 (int), influenceJointId_1 (int), influenceJointId_2 (int), influenceWeight_0 (flt), influenceWeight_1 (flt), influenceWeight_2 (flt)
• if an a point is driven by less influence than the max number, we assume the influence id to be -1
• we assume all influence to be ordered by weight, and as soon as we encounter an influence id of -1 (or weight of 0), we stop
• typically we don't build an internal lookup from the primvar data, but use the data directly to prevent redundancy of weighting information
• while on paper this seems like a waste of space on the primvar side (especially when the amount of influences is differing greatly) we found that due to primvar compression etc this has not turned out to be an actual problem
• a nice plus of storing data this way is that the interchange of weight information with other applications (maya, houdini etc) via any of the supported file formats becomes quite easy

[carstenkolve]

If we take this approach, we need to make sure the Generator removes those primvars so they never hit the renderer. I'd propose to have a dedicated section as to which primvars are being inherited. so if someone really wants to get them past the generator, they could add it (similar to the copy sop in houdini)