I'm writing a deformer broken up into two nodes much like the “clothdeform” and “clothcapture”. I'm storing weights on the capture and reading them in on the deform.

When I make an array attr in vex like this:

for(int i = 0;i<10;i++) {
float weight = 1;
f@weight = weight;
}

I get something in the spreadsheet that looks like:
weight


that's a different format then the clothcapture and the attributeCreate nodes provide.. that looks more like

weight | weight | weight | … etc
1 | 1 | 1 |

(excuse my ascii art)

My node works with the compact one() but it's really slow to read in to my deform vex node and I'm wondering if the way it's stored is the issue. Is it possible to create an array attribute in vex that looks like what you'd get from the attribute create or cloth capture nodes?

daniel

You want to check out the capture pack / unpack nodes. I use them for overriding wire deform and cloth capture weights. Weights for capture use a special ‘index pair’ type that isn't directly usable in vex… so the nodes allow you to convert to regular arrays and back.

https://www.sidefx.com/docs/houdini/nodes/sop/captureattribunpack [sidefx.com]

https://www.sidefx.com/docs/houdini/nodes/sop/captureattribpack [sidefx.com]

Thanks Ian, I'll take a look. Looks like some of the text in my message was screwed up but sounds like you figured out what I was after.. I meant to say I'm seeing attrs like in one column of the spreadsheet rather then a separate column per index. I'm curious if one or the other style is slower to read in vex

Some more info. I'm finding that capturing and deforming all in one vex wrangle node is faster in my case then capturing in one vex node, storing the weights and deforming in another. I want to separate the two because capturing only needs to happen once.. but it looks like reading in large arrays of capture data is slower then doing the capture itself every single frame in my case. My capture data is non-standard so it's arbitrary data not compatible with any of the houdini deformers, just large arrays of data per point. I'm still hammering at it to make sure I'm not doing something stupid

As you're hinting I would agree that the creation, saving and re-loading of the attributes could be the slow part, especially if it's a large number of elements in the array. I even remember loading geo with cloth capture attrs still saved and it was pretty slow just because of the attribute size. I would guess that if your capture is not time dependent, is only the length you need (ie: only capturing 10 points instead of 100) and that if you're not recalculating anything again for the deformation, but just fetching data and setting new positions, that there isn't much you could do to speed it up. Make sure you look at the performance monitor too, and maybe try with the geometry spreadsheet closed so it doesn't have to display all the data?