Not sure what’s happening here, but it’s messing up my ability to use the tree.
I’m using Contour.
How the tree goes in:
How the tree comes out:
Jumping from 5 to 10 to 15 in the middle branch is kind of weird, no? The other inputs to Contour are single items.
Why does this happen? How can I change the tree to resemble the original structure with a new set of items appended to each branch for the contours?
issue.gh (34.3 KB)
so what the contour component does is renumber the paths
so {a;b;c} is item b in the original list.
The other issue I run into is no intersections on the first two diamonds.
you will need to fix it for the trim with region to work properly.
I would recommend using another “tree stat” and “Tree branch” to get the correct path for the trim with region.
issue.gh (31.3 KB)
Interesting, will look this over. Why does contour do that?
Behaviour seems like a bug.
Numbers should be matching since it seems to be matching the first item in the path, but not the second.
@DavidRutten this seems to be a bug in the contour component.
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.
P.S. Playing with the ‘Pitch’ and ‘Width’ sliders, I see this fails miserably in some cases.
P.P.S. I see on the DUPLICATE THREAD that you are considering “around 100,000 lines inside dozens of closed curves of various shapes”. This method is probably too slow for that.
Sometimes it’s hard to see the forest for the trees… This simpler method is 1.8 secs. instead of 7 secs.
Interesting way to use Perp Frame. Also hadn’t seen the Data Dam trick before.
Not sure if this thread counts as duplicate. I’m only asking about this one specific confusing behavior of Contour.
It looks like a duplicate to me.
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?
No more Data Dam, the Anemone loop restarts while moving any slider.
I haven’t used Anemone before. Out of curiosity why are these solutions so much faster than previous ones?
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.
You are right! It’s legacy code from earlier versions where I was using that white line for pFrames and is no longer needed. I love it when code gets simpler, good eye!
Revised:
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? 
That makes me happy. 
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.)
Further simplified.gh (60.9 KB)
YES! Those features are there for a reason. In fact, I used Anemone because there were edge cases that failed miserably. Pottery Barn rule applies: you break it, you own it.
Not at the computer now, maybe tomorrow or maybe I’m done.
I keep finding params like this. Would love to know why it’s more likely to break.
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.
I think I’m good on this one. Thanks again!
