Working with these nodes is striking me as very mysterious. I'd like to know more about the index/pair data type, how to access and work with it, and whatever else the proximity capture might be doing under the hood.

I'm making thousands of capture envelopes to deform vegetation. I have a system working and it's at an “acceptable” level of performance, but it's a pretty gruesome hack to get it there.

For each spline, I'm making a bunch of envelopes, foreach looping through to only get the right geo for each branch, then making a primitive number “offset” and offsetting the boneCapture1, boneCapture3 attributes. I'm also hackidy-hack renaming the various path attributes .. boneCapture.pCaptPath (I don't see this one anywhere in details, but found it with the attribStringEdit node. And then the pCaptSkelRoot.

The thing I'm really struggling with is that there seems to be a “limit” set as for the primitive number of the boneCapture index/pair attribute. If it exceeded this number, the attribute broke (values disappeared). I managed to fix this by merging, then deleting a capture proximity with a full set of capture regions. So, I'm guessing it's some sort of an invisible detail attribute.

So, I've got everything working .. but I'd like to have a cleaner workflow and any other information that is known about how that stuff works 8)

Hi Andrew,

The hackidy-hack rename of the boneCapture.pCaptPath isn't working in H14 anymore. Support told me to try and use this python script (https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=38227&sid=8d37bbeefe9ebc38587fb51b99be48e2 [sidefx.com]) to extract all index pair attributes and then make a custom vex to rewrite the attributes as needed.
That's quite a daunting task given my limited coding skills and the python script errors out with a “tuple index out of range”.
I haven't been able to find a solution yet and was wondering if you have found an alternative way to edit the boneCapture attribute.

Cheers

Rudi

not derail the original question but…
why are you capturing/deforming vegitation like this?
is there are reason you're not using wireCapture for example?

just interested in what you're trying to achieve as there may be a better method.

Hi Michael,

I briefly tried the wirecapture/deform but in a tree with lots of branches it's a lot of work to get he captures correct. They come in default at .3 to 1 iirc and that overlaps heavilly with neighboring branches. Manually adjusting 200+ capture regions is quite a hassle, specially because i couldn't select the individual capture regions in the viewport.
I hope it's clear and you can tell me i'm doing things totally wrong :-)
It did become kind of a principle challenge for me as well, to understand this index pair attribute form of data.

Cheers

Rudi

I also had issues on a similar project. Which method is the best for capturing the deformations for tree like structures simulated using wire dynamics?

I tried wire capture too but it doesn't seem very procedural. It would be nice to be able to control the parameters of the capture using the same or modified attributes that are on the wires i.e. width. Is this a reasonable RFE or am I using it incorrectly?

I found that using Point Deform works well, but you lose some detail and of course it would be more desirable to be able to capture the deformation using wires instead of point clouds.

ah, ok….you're doing what I thought you were
wires are MUCH better for what you're doing - but the workflow can be a bit tricky….

Andrew Lowell has a course at FXPHD that uses boneCaptures as well…but the same can be done with wireCapture…

the use of a forEach can help in seperating out branches…

It would be nice if the Wire Capture SOP could be driven by attributes. A VEX implementation would be useful so you can capture everything at once.

Anybody has done this before?

The current workflow seems shaky IMO.

there is a way to paint wire capture attributes - but it's VERY clunky…

arctor
the use of a forEach can help in seperating out branches…

That's the thing, his tutorial uses exactly this technique, but to get the right primitives to the right wires he uses a trick which consist of a addAttrib using a float 4 for 2 influencers. This worked perfectly fine in H13 but in H14 it doesn't because the values of the index pair are “protected” and can only be edited with a attribute string edit.
According to Silvina, i could write a vex sop with the addattribute function specifying the type to index pair manually. This must be doable but is a bit hard for me since i do not have extensive Vex experience.