Custom Vex Op To Compare + Modify All Points?

[emcjagger]

Hello,

I'm trying to design a system where a line is drawn as directly "upward" as possible through randomly scattered points. I'm trying to do this using a custom Pop written in vex, but I'm having some trouble. Currently, the vop:

1-starts with the user designating one of the points as the starting point - the "tip" - and initializes the generation counter (gen) to 0.

2-assigns "gen" attribute to that tip (needed to construct the poly line in the right order).

3-adds that tip to the "toPoly" group

4-loops through all the points in the system and finds the one which is most directly over the tip

6-designates that point as the new tip and increments gen.

7-repeats this process from step 2 until there are no points above the current tip.

Here is the relevant code:

	do {
		// Add each tip to "toPoly" group, which will be used to make a poly line.
		addgroup("toPoly", tip);


		// If the current point is a tip, assign the "gen" attr to show which 
		// generation.  Needed so the line is constructed in the right order.
		// BUGGY:  If you just write 'addattribute("gen", counter);', it seems
		// to always add the attr, regardless of whether (tip == ptnum)
		if (tip == ptnum) {
			int gen = counter;
			addattribute("gen", gen);
		}


		// Iterate through all points to find which is most directly over the tip.
		overTipMax = -1;
		int overTipMaxPt = -1;
		import("P", PtTip, 0, tip);
		for (i = 0; i < Npt; i ++) {
			import("P", PtI, 0, i);
			vector tipToPt = PtI - PtTip;
			float overTip = dot(normalize(tipToPt), {0, 1, 0});
			if (overTip > overTipMax) {
				overTipMax = overTip;
				overTipMaxPt = i;
			}
		}

		// Point most directly over tip becomes the next tip.
		tip = overTipMaxPt;
		counter ++;

	// Break when no points are over the tip.
	} while (overTipMax > 0);

The main problem is that vex seems designed to only deal with one point at a time, not the whole geometry - implicit rather than explicit processing, one might say. This means that, if I understand correctly, all the code must be executed for each point. This is extremely redundant since exactly the same processing of the same data will be done for each point. I tried applying the sop to just a group containing only the original tip, which almost worked. The problem was that I need to assign the "gen" attribute to each tip, and in order to know which points will be tips, I need to process all of them.

What I WANT is very similar to the above, but only excuted once, querying *and modifying* all the points in the geo. This could work if only vex had a way of assigning attributes to points other than the one being processed. Is this just too against the vex paradigm? I sense that I'm already pushing vex's intended usage, given some quirky behaviour (see the BUGGY comment in the code). Is there a better, non-vex way of approaching this problem? Keep in mind that this vertical-line growing exercise is hopefully a precursor to more complex, organic, pattern recognition schemes -- eg. finding, circles, faces, etc. in random particle scattering -- so general advice is appreciated as much as specific help.

I've included a .tar file with the original .vfl and .otl files, as well as a demo scene. If you go to /obj/geo1/ and view through cam1, you will see a hudslider that rotates a randomly preturbed, templated grid, and a line drawn through its points using my vex sop.

Many thanks in advance,

Jeremy.

growSopFiles.tar

[sibarrick]

Just a quick answer.

Two things to try

1. Try the HDK - you have found the limits of Vex, it isn't designed to build geometry.

2. You could try processing things a different way. Feed a line with say 100 points into your vex sop,

then feed your cloud of points into a second input. Write your code to re-position the points in the line using the cloud of points only as a reference. Group the points that you end up moving, then just add a sop afterwards that deletes the points that didn't get moved. This way you have the connectivity already setup and aren't trying to build any geometry.

[Mario Marengo]

One more HDK-less idea to add to Simon's...

3. Use the point cloud tools. Point cloud traversal is explicit, and in SOPs you have the advantage that you can use the "op:" syntax so there's no need to save to a file. In this case, you'd use pcunshaded() to tag the valid points (and their "vertical order") in the pointcloud. This would happen only once due to the way pcunshaded() works (assuming you include all points in your initial scan). The rest of the SOP then opens up the (now "tagged") pointcloud for the point being tested, looks up the attributes you stashed in the point cloud, and groups the actual geometry points accordingly.

Haven't tested any of this so I might be missing something... but worth a try.