Hi all,
I'm currently working on a project where I need to look at the points in a mesh, and then make a certain percentage of them pair off with one another, pairing with the closest if possible.
Now…I sort of did it, but I'm debugging my it at the moment as some pairings are not working properly (they are being paired with already paired points). Here's a stripped down version of my code (as a side note, the points are dynamic, so I have to use stored point id in an attribute called ‘id’);
if(i@paired_pt!=-1) return; // Does this work correctly?

int close_pt=-1;

int handle = pcopen(0, “P”, @P, range, pt_count), pt;
while(pciterate(handle)){
if(pcimport(handle, “point.number”, pt)){
if(pt==@ptnum) continue; // The first one is always the current point
if(point(0, “paired_pt”, pt)==-1){ // Is this point already paired?
closept=pt;
break;
}
}
}
pcclose(handle);

if(closept==-1) return; // No match so just exit
i@paired_pt=point(0,“id”,closept); // Find the actual id of this paired point
// Is this actually updated, so the comparison at line 0 will work properly when it is evaluated?
setattrib(0, “point”, “paired_pt”, closept, 0, @id, “set”);
So…does the setattrib function actually set the “paired_pt” attribute so that the comparison at line 0 will work properly?

tldr; In a wrangle SOP can attributes that are set be read in the same loop?

setattrib() is applied as a post-process after all the code has run. This is very important to enforce consistency as we process points both out-of-order and simultaneously.

This is also why our sand solver doesn't use a gauss-seidel approach to the update.

The simplest solution is to switch the wrangle to Detail mode and explicitly run over all points. Then you can have an int array store if things are paired.

The alternative is to do simultaneous pairing of all points, possibly generating duplicate pairings. Then have a tie-breaking rule clear out the redundant pairings, and do a for-loop at SOP level until all points are paired.

Both approaches have an issue with this setup:

G A B H C D

Imagine A & B and C & D are close to each other. So they pair up. This leaves G & H unpaired, so they pair. But they are very far away, so you'll be surprised at very distant pairing occuring. In one dimension, the solution is straightforward: sort on the axis and pair that way to get GA, BH, CD.

Thank you for taking the time to answer jlait.

I'm guessing that in detail mode the point wrangle need to use the npoints function to iterate over all the points, store things explicitly in arrays and use the point function to get attribute values?
(I'm relatively new to the wrangle nodes)

Correct, it will, so it will not benefit from any multithreading/SIMD acceleration of the operations. Thus it is usually beneficial if you can re-think your needs in a fashion that lets you keep it a for-all-points approach.

Indeed. In this case of pair matching I'm not sure if it's possible to. If you or anyone else has any ideas I'd love to hear them.

On a related note concerning wrangles:

• While iterating though points using Detail (only once) - Is it best to use point, getattrib or import?
  
• I'm still not sure I understand the different between the wrangle nodes. I think the attribute wrangle is the only one that can alter geometry, and the others are just the same node that runs over different entities (points, prims or verts). Is this true? Is there anything else I should know about the differences between them?
  

point() and getattrib() are almost aliases of each other. Use whichever one best suits your coding style. Not sure which you refer to with import()? pcimport() I tend to instead use point() as it is more consistent for me.

With 15.0 there is only one readily accessible type of attribute wrangle. Point, vertex, primitive, and attribute wrangle all are the same node, just with different initial values. So they can all alter geometry the same way. It used to be we had a “point wrangle” which was different, and couldn't do setattrib(), etc. But everything should now be unified.

Volume Wrangle is, of course, rather different as it is dealing with voxels, not attributes.