# VEX SIMD vs. Remove coincident primitives

## Recommended Posts

This thread is also about the order of execution (setattrib, remove geo, add geo) and comparing if(@processed==0) of un-initialized @processed attribute.

I was trying to script "remove coincident primitives" (or at least group them) in a single wrangle and I realized that I don't understand some invisible details of VEX execution.

Is it possible to run VEX over big number of primitives, compare each primitive to each primitive, remove duplicates, and also set "@processed=1" attribute and speed the execution by skipping processed primitives?

Below is an example from Entagma tutorial, https://vimeo.com/227701595, by Manuel Casasola Merkle. But if I understand it right, over big number of points, he may get multiple "same" results? Which in this case is ok, but in my case of "remove coincident primitives" it is a problem which cannot be "tricked" in one primitive wrangle?

Please, if you understand my "SIMD and execution order" confusion, could you direct me?
(fast non-vex way to remove coincident overlaps is PolyDoctor SOP)

```float rval = rand(@ptnum*@Time*1245687);

if (rval < 0.01 && @Time > 2.0){

int nearpnts[] = nearpoints(0, @P, 1);

foreach(int pnt; nearpnts){

int tarmyprim = point(0, "index", pnt);
int tarprocessed = point(0, "processed", pnt);
int taringroupends = inpointgroup(0, "ends", pnt);

if(tarmyprim != @index && i@processed == 0 && @group_ends == 0 && tarprocessed == 0 && taringroupends == 0){

vector tarpos = point(0, "P", pnt);
float length = length(@P-tarpos);
setprimattrib(0, "restlength", nprim, length, "set");

i@processed = 1;
setpointattrib(0, "processed", pnt, 1, "set");

setprimgroup(0, "connectors", nprim, 1, "set");
//break;
}

}

}```

##### Share on other sites

Hi,

This is a fast way:

You can see the VEX code inside.

• 1

##### Share on other sites
On 6/22/2018 at 9:22 AM, ikoon said:

compare each primitive to each primitive, remove duplicates, and also set "@processed=1" attribute and speed the execution by skipping processed primitives

Yes,                                                            yes,                                         yes,                                      in general, no.

When you write code in VEX (or use VOPs) you are reading attributes from the input geometry, not the geometry you are currently processing.  This is the mechanism that allows VEX to run multi threaded SIMD code.

Though that's just high level theory; you can't read and write to the same data from different threads haphazardly.

• 1

##### Share on other sites

Thank you very much for your answers. I think I understand it now, we have to do the duplicity removal in two wrangles. One Primitive Wrangle to create the list of duplicities, and second wrangle to act on the complete list (collected from all the first wrangle's threads and primitive subsets).

As regards the Entagma code, it can create duplicate connectors indeed. In one (sub)frame, if the random condition is met from point A to B and also from B to A. Even if we set and check the @processed attrib. Which is allright, I just had to grasp it. Thank you very very much for your help!

## Create an account

Register a new account