As the output says “Resulting contours (grouped by section)”, it is doing something different. It seems to me that it is taking the last index of the original branch, adding the global index (DA.Iteration) and finally the index of the intersection with that object. If it does, it doesn’t work well. I don’t understand why each result is in its own branch or why it only takes the last index of the original branch.
I struggled for awhile to get an elegant solution, saw the data tree conflict and finally gave up.
This is slow (7 secs.) but effective. There is a Data Dam(red group) with a two second delay to allow adjustments (blue group) to the length and angle of the white line which is perpendicular to the strips.
Those strips are organized to match the ‘Input Regions’ data tree.
Several versions later… I tried the two shapes you used in the other thread and immediately saw issues so resorted to Anemone to handle one region at a time. Appropriate line length is determined automatically for each region. Eventually I ended up using Clipper PolyOffset again. It looks fairly fast using either of the two data sets (yellow groups), though will surely fail if an “Input Region” (surface?) has holes in it, whereas the slow version ‘b’ above might work?
For one thing, it works on only one region at a time. For another, I used the “Fast” Anemone components instead of the slower “Classic”, which shows visible progress while the loop is running. The “Fast” loop components run in stealth mode, showing nothing until the loop finishes.
I have to admit I don’t understand why working on one at a time would go faster when there’s no obvious dependency between what happens in one region versus another.
I’m looking over your Anemone script I think I understand it except for the part with Plane through Shape and Brep | Brep. This seems like a very roundabout way for creating the Direction (N) parameter for Contour. If I feed the geometry from the Rotate component directly into the Direction (N) input it does the same thing but rotated by 90 degrees. Why is this important and why not just add 90 degrees to the original rotation?
Edit: Also not sure what the function of the Point input to Contour is (it seems to work without it, though creates slightly offset lines?) It’s an interesting solution so I want to understand what’s going on.
This model still assumes that all regions are in the World XY plane (or parallel to it?). It could be modified easily to determine Plane Fit for each region separately and use that to handle any arbitrarily skewed region. For VRot, Contour and PolyOffset… Uh oh, what about BBox?
I don’t expect the design to ever be on any plane but World XY. Does that mean I can get rid of DeBrep and List Item? I also suspect I can get rid of the BBox Scale which also eliminates Area. It all seems to work without those four components. Is there a breaking edge case I’m not thinking of?
(Also added a small modification where there are different angles for each region which is more true to my actual need.)
Rats. You got me curious so I looked at my code, not yours… Scale is needed because the PolyOffset curves will fail to cross the region edges completely, leaving right angle corners on the strips that don’t get trimmed. The scale factor of 2 might be excessive after dropping the pFrames approach but was necessary at one time. The ‘P’ input to Contour was done so that each region has its own start point. You better push parameter limits and look carefully for little flaws before throwing stuff away.
I’ve had my fun on this one and don’t wish to review your code changes, sorry.