Trim interior lines in intersecting closed curves

I’m trying to find a way to do this in C# or Grasshopper. I know how to do it manually in Rhino by using my eyes to find the lines I don’t want and trimming them away one at a time. A Rhino command that automagically did it would also be awesome.

I have multiple closed curves, some of which intersect each other one or more times.

(EDIT: Dang it! Ignore the golden yellow line, I forgot to hide that.)

I want to trim away the interior lines where the closed curves intersect, ending up like this:

The intersect command will find the intersection points but not the interior lines.

I can’t just delete lines that have start and end points equal to the intersection points because sometimes the closed curves intersect more than once.

I know how to get a list of all the closed curves in any of the possible solution environments.

Any tips on how to proceed? I’m trying to figure out an algorithm that would identify the lines I want to trim away. (But I won’t turn down a complete solution either! :slight_smile: )

Hello - I suppose I’d start by looking for four intersection points that are within some distance of one another and trim the curves at the parameters there using the ‘interior’ interval -
But it will get complicated as the number of curves start to multiply - keeping track will be a headache I imagine.
That is what comes to mind anyway…


Not positive, but I think the attached definition takes care of what you’re trying to do.

Intersecting (11.8 KB)

I had to first create the closed regions and used some offsets in the red/green group to do so which you can probably bypass.

So, all together, if you input your purple curves (as planar closed curves) into the ‘double curves IN’ node (purple group) the ‘curves out’ node in orange should give you what you need.

For reference I used the ‘Trim with Regions’ node along with some data tree re-organizing and culling to trim each shape with every other closed region except itself.

I also believe this solution does not work if the closed regions are self-intersecting.

Thanks! You’ve worked on what I’ve been working on!

I started learning Grasshopper last Friday. I had already worked out the first part, creating the offsetting curves on both sides and capping them flat. My approach tests for closed curves and doesn’t cap the closed curves as they don’t need it for my purposes. You’re making much better use of the built-in commands and I was using C# script components to handle some of my tasks. I want to study yours and better understand it, then modify it to not cap the offset curves that are already closed.

I’ll post my finished version when I’ve merged in what I’ve learned from you.

I tested the trimming and it’s close to what I’m looking for. Again, you’ve made very good use of the built-in components. For the offsets for input curves that started off closed, i.e., a circle, the trim code is removing the inner offset line and both caps. That’s a no-go for my purposes, I need to keep the inner offset line. I’ll go thru your code and see whether I can modify it not to do that.

Again, I’ll post back with that, too. It’s possible that the first change (not capping already closed lines) will solve the second problem. One can hope! :wink:

You’ve given me something to chew on!

After I get this utility done, I have several more to do. The first will be a quality control check to identify any offset lines that are (a) open, (b) self-intersecting or (c) bad objects.

The next will be one that looks for offset lines that are too close for too long. Those closed offset lines will be extruded into solids that will be cast into metal and if they are too close for too long they will trap air bubbles and cause the cast to be less than perfect. I want a quality control check so I can toss the offset line layer contents, modify the original drawing lines to be less likely to trap bubbles, and re-run the utility to create new offset lines.

The next one will extrude the offset lines into solid extrusions and then convert them to closed polysurfaces.

And the final one will be a quality control report that marks (a) bad objects, (b) naked edges and (c) non-manifold objects.

Just a note since I don’t know that I worded my post well.

The red and green groups were just my way to re-create your original input data, but the purple, blue, and orange sections are what I think you actually need or would use. You can delete the red and green and use your purple curves as a list of inputs into the ‘curve’ node I placed into the purple group.

It sounds like you’re on your way to a solution, but if you’re able to provide some sample rhino or grasshopper data as a starting point that always helps with problems like these too.

Test offset and trim.3dm (37.1 KB)

This has a variety of conditions in it to trip up an algorithm. :slight_smile:

I usually do an offset of 0.075 in each direction in my production work.

Updated test file with additional test conditions and a layer with the desired results. Offset distance slider set to 0.075 for desired results.

Test offset and trim.3dm (79.8 KB)

Updated script based on that of Mxmiceli. Pre-closed input curves (like circles) no longer have “end lines” to cap the offset lines on both sides.
Intersecting curves (32.3 KB)

I’m still working my way thru the trim portion of the file. I kinda-sorta understand it but not quite. There are two paths thru this portion of the file, one is a list of sets and the other is the list of curves per set. Currently they both derive from the full set of offset lines. I’m wondering what would happen if the set of sets was limited to those offset lines that did not derive from the pre-closed input curves. But I have more reading to do on the commands in this section before I give that a whirl.

I took one more stab at it since I saw your file had a lot more unique intersection cases regarding closed, self-intersecting, and curves closer to each other than the offset parameter distance.

I think I’ve got a comprehensive solve for it here.
Intersecting curves max (29.5 KB)

It’s quite a bit more complex, and not very elegant or efficient but it handles all the edge cases correctly from my test and a few others like self intersecting closed curves (figure 8 curves) which you can see in this test file.
Test offset and trim max 2.3dm (84.4 KB)

Essentially, what it does is first split self-intersecting curves into closed loop and open segments since GH’s curve offset was not handling them correctly. Then using a similar principle to my last script, it does a curve intersection test between each curve and every other curve in the scene except itself, followed by a ‘shatter’ node to create a lot of shorter segments that are each split where they would overlap with any other curve.

Then each shattered segment has it’s midpoint tested to see if it’s within each thickened line. I made a modified offset section for the closed curves to prevent them acting like circles and instead making them join in a specific order to create a more useful closed loop for this type of test. Then I remove segments that fall within those loops leaving only the segments we actually want.

Finally, at the end I was getting some occasional non-closed curves which seems like a precision issue with the ‘point in curve’ node so ended up doing a final logic test that removes the shortest segment from any non-closed loop which has cleaned up any issues I’ve seen.

Interesting problem to solve, hopefully this helps.

That is awesome! The output is spot-on correct for what I want.

I’ve been working my way thru your original trim solution, trying to do some of the steps, but it’s been slow going. The written grasshopper documentation is often “a bit terse” and lacking in detail or example. Most of the explanations I’ve found have been video and that’s been a problem for the last week – my motherboard died and when the Dell tech replaced it he left off the audio daughterboard, so that source of documentation has been closed. Thankfully that got fixed this morning so I can now watch and hear them.

Thanks for the detailed explanation of your algorithm, it will help me understand which parts do which.
As I add additional capabilities I’ll post them back on this thread.

The Offset portion of the file makes perfect sense to me. Still noodling on the rest. It will take awhile to understand what all the components actually do, and that’s essential before I can understand how they work together. You’ve given me a lot to puzzle thru!

As I puzzle it thru I’ll modify it to add additional comments and groups to document what part does what, and post it back periodically.

@ Mxmiceli, I’ve been going thru the file and adding groups and comments (scribbles) to it to better document what’s going on and why. It’s past midnight and I’m calling it quits for the evening. You can see how far I’ve gotten thru the file.

Intersecting curves max (46.0 KB)