I am cleaning up linework from a map drawing and typically encounter a few self intersecting curves that are easy to select with _SelSelfIntersectingCrv, mark with _IntersectSelf, and then fix. I am noticing today that a number of curves are not being marked with a point object, but instead a line. Is this intentional? Is this documented somewhere? If this is intended behavior, I really need it to at least be dropped onto it’s own layer. I only found this because I selected the whole map and noticed that I had open curves added to my selection. Here’s a 3dm file with one of these curves. To repeat, run _SelSelfIntersectingCrv then run _IntersectSelf and it will drop a straight line onto the overlapping corner.
The problem with this is I didn’t know to look for these lines and now I’m having to check my file open curves. Test_SelfIntersectCurve.3dm (42.1 KB)
Thanks @davidcockey I opened this curve in V7 and it drops a point as expected. This certainly feels like a regression to me. The V7/V8 documentation indicates it should be a point object and says nothing about curves.
Imagine this: I’m processing many lines and 100 of them come back as self intersecting. I run _IntersectSelf and it marks 89 of them with a point. I have to know that some of these self interactions are marked with a line and then I have go go find them. I’m lucky today that I’m dealing with all closed curves and the tiny curves generated with _IntersectSelf are easily selected with _SelOpenCrv.
I foresee users including myself not knowing to look for these small curves, extruding them and making making our files progressively massier.
As someone who processes a ton of maps for fabrication this is extremely anxiety inducing.
Hi @ryan.odom. I’m new at McNeel and will be taking over the intersector code. I can’t speak to how things were working in V7 vs V8, but the new behavior that you’re observing is “correct”, like @davidcockey says. The new behavior is definitely not a regression.
Maybe we can figure out a way to make the tool behave more intuitively and predictably so that it doesn’t mess up your workflow. Please let me know if you have any suggestions.
The problem is that I need to be able to easily identify the location of the self-intersections, modify the curves, and delete the marking objects. When some self-intersections are marked with a tiny curve, they can be missed, overlooked, or worse: extruded into surfaces that become part of CNC file where they trickle down and become an issue during tooling. It makes sense that regardless of the type of intersection, the marker would be the same when running this command. There are numerus ways that a curve can geometrically intersect itself. In the example below of a few self-intersecting curves, one type of self-intersection (#2) produces a different kind of marker from all the rest and #3 doesn’t produce a marker at all btw. Points never get lost amongst other curves, but tiny curves absolutely do. What if I’m processing a file that does contain many tiny open curves as part of the file? How could you possibly differentiate the marking lines the others Especially if you don’t know you’re generating them?
I don’t understand why it changed. What problem is this solving when it worked just fine in V7? Who asked for this? My best guess is that its highlighting the overlapping portion of the curve to show which part bad, but I have never needed to known to this information. I just need to be able to locate it and fix it. If you spend any amount of time manually editing for self-Intersections, you will find that it is abundantly clear as to which portion of the curve needs to be revised.
This is going to cause headaches and waste a lot of time.
There’s a command in Rhino called SelLast that you may find useful. If you run it immediately after running IntersectSelf then the overlap segments will be selected. You can then run CrvStart and CrvEnd to drop points at the start and end of the overlapping segment.
If you run this macro (just paste it into the Rhino command line), you’ll get two points instead of micro segments:
You could make this a button or alias for your users.
As for Why:
Overlap intersections are an important thing to be able to detect. They’re actually different from transverse intersections, and need to be handled differently. In your case, perhaps the two points are good enough, especially if you have humans dealing with the resulting points. But for true automation, having the full overlap event is actually quite useful.
RH-49835 ON_Curve->IntersectSelf() doesn’t detect intersection in this curve
I found the YT Issue above that seems related to this “enhancement”. Rhino 8 reports the number of overlapping segments found in the command history window and creates curve segments. The command topic has been updated to include information about self-overlaps.
Thanks @brain and @sfp I do understand situations where this this could be helpful. However, it appears the IntersectSelf command is riddled with reporting errors and lacks functionality most people need: identify problem areas.
Take for example these three self-intersection curves that I drew
Now, if I select just curve 2, or curve 1 and 2 without curve 3, the command reports finding 0 self-intersections, though it does draw the overlapping lines. This is problematic because * need to know what objects Rhino is creating and in a larger file like the map below this can be a daunting task
The map below is a real use case where I need to remove self-intersecting curves and prepare it for CNC fabrication. The linework was imported from other software.
The self-intersections marked with points are easy to find and remove. Now that I know there are lines marking intersections, I can make sure they land on their own layer, but they are still harder to identify. Sure, I can run CrvStart and/or CrvEnd, to mark them clearly, but I often have interns who sit in offices around the country helping to process linework and I don’t always have the agency to teach these nuances.
Additionally, InterectSelf does not like some closed curves. When the command is run on the curve highlighted here, it is duplicated twice along with an open curve marking the overlapping portion. It took me an hour to figure this out and it was only when I brought the linework into V7 that I could see what was going on. See file attached below. None of this is a problem in Rhino 7
Here’s what I need for this essential functionality to continue using V8:
Reporting accuracy. I nee to be able to rely on the information given to me in the command line.
IntersectSelf sub option allowing the user to create only point markers. Both Start/End Points of the overlapping region would be fine
Option to group objects generated to mark self-intersection when curve and point objects are the output.
I need it to just work out of the box. Micros are great, but this is a common enough workflow in architecture and fabrication whe processing SVG and GIS data that it needs to be universal. Test_SelfIntersectCurve2.3dm (3.5 MB)
This SGV import bug from 2023 is related, but is a distinct problem of it’s own that has not been resolved.
I went ahead and put together a YT issue for the bug you noticed (RH-86495 Inconsistent IntersectSelf text output). Let me know if I’m missing anything with this.
Re: “Additionally, InterectSelf does not like some closed curves. […]”: I had a hard time replicating this one (specifically, the screenshot showing three green rectangles and one red rectangle all overlapping). I’d like to get a YT issue filed for this, but I think I’ll need a smaller file with just the problematic geometry in it along with clear instructions for how to reproduce. If you have a chance to put that together, I’ll be happy to look into this bug for you.
Let me know if I’m missing anything here…
Now, for your workflow, I want to try and mock something up that will work better for you. I agree that the way the results of IntersectSelf are displayed can be improved. One thing to consider is that this command is supposed to work on both curves and surfaces, so it is really important to be able to mark a few different kinds of intersections and overlaps. Two surfaces can overlap, so just dropping a point on that kind of overlap isn’t going to cut it in the long run. So we’ll need to come up with something more than just “drop points on the intersections and overlaps”.
I mocked up one idea for your case in the attached file:
Manually change the color and use a custom linetype to give the overlap curves a thickness of 5 pixels—this appears to render with 5 pixels regardless of how zoomed in or out you are.
I also tried a variation of this where I dump all this together into a single layer and make sure to BringToFront the intersection events, although I’m not sure if this is really doing anything…
This seems like a good workflow that @ryan.odom could adopt without any macros. I’m concerned that if we caused Rhino to force output objects to be a different line type and color that we’ll actually mess up other users.
Also, there are so many zillions of ways to use Rhino that macros are central to making it work well in specific scenarios. I’d encourage @ryan.odom to reconsider the use of macros to get exactly what he wants. If necessary, I can show you how to share a button with your interns so they don’t need to know anything exept how to click the button.
