To create the geometry of crossing streets, I’d like to speed up the Trim with Regions operation. The desired end result should not have curves crossing over (such as in the light grey sidewalks below):
The downside however is that it is much slower than a multiple curve intersection. So I’m thinking that if I can use multiple curves intersection, then test for whether a segment midpoint is contained by the curve that I trim with, the segment can be culled. However, I can’t quite get the data trees to match up.
I think Trim with Regions is pretty fast . Although the multiple curves intersection (mcx) component can work faster, testing for containment afterwards might actually take longer?
Trim with regions can be sped up too with an MCX and supplying the correct curves to trim in advance (so there are no curves that don’t intersect). I got close here, but the Regions to Trim with are incorrect.
This is with 9 curves and I’ll likely have some 40-50-ish curves for my masterplan. It’s about equally quick on my end. But if I can make it 1/6th quicker by preprocessing, that would be nice.
Since I can’t visualise the end result, I don’t know if all the curves end up intersecting correctly on beforehand.
They can easily overshoot or fall short.
Only after the intersection will I be able to know if there were any curves that require a rework (I do this all only with the orange lines from the earlier picture).
That’s why, I was trying to use the shattered segment parameters to find which curves intersected so I only do a containment check between the shattered segment midpoint and the curve(s) at their start/ end point (the ones that are used for the actual trimming). If a segment is contained in the curve that intersected it originally, it has to be trimmed away. I hope I’m making sense here.
Also each branch in MCX corresponds to a section zone (sidewalk, road, bicycle lane), so for the 250 intersection points I have know, I’d have 500 containment checks tops. Less if I filter out the long segments.
As far as I can tell, I’ve only used Human (for a stand alone colored preview) and Pufferfish’s Curve Middle. I’ve replaced those components here: Trim with regions sped up_no plugins.gh (200.8 KB)
Do note that the Custom Preview Component’s colours are way off and aren’t really distinctive enough now.
I decided to try the flattened Multiple Curves intersection first, which is in the file below. However, there’s still something wrong with the shatter, I grouped the likely problematic components.
you create a set of the indexes of the intersecting curves, then use member index to retrieve their relative position in order to get shatter parameters
for instance, here curve at index 4 and 5 do not appear in the list, meaning there should be no shattering parameters for curves at index/branch 4 nor 5:
still, there are branches for shattering parameters of curves 4 and 5 in the output tree, and that happens because there wasn’t even an interrogation to Member Index about indexes 4 or 5
a maybe better way to do that is to create a Serie which is as long as the initial Curve List, and use that Serie to interrogate Member Index instead, this is how the tree with shattering parameters changes:
. Although the multiple curves intersection (
