I was in need of a very efficient and robust tool for curve offsetting. The best solution I found was Clipper2GH by seghier, which unfortunately is no longer mantained, the author allegedly had himself deleted from this forum.
I ran into an apparent bug which creates “spikes” of line segments between offset and original lines. I tried all my knowledge to spot the possible cause outside the component itself (cleaning, culling, rebuilding) but the bug really seems coming from Clipper2GH. I also tried changing some parameters upstream to generate slightly different inputs, but the bug just moves randomly somewhere else on the curves.
Given that it is bound to the polylines realm, I found a correction algorithm which wasn’t available in any other plugin I know. It consists in spotting two overlapping segmets into a polyline and delete both of them while keeping the rest of the polyline.
I am sharing a file showing the issue and the resolution, hope this will be useful to someone. It can be easily modified to spot lines which aren’t perfectly overlapping, but within a certain tolerance (just change the “0” in the length comparison with the treshold value)
I also making a call to anyone who knows a tool which can do offsets like Clipper2GH:
fast (in my example 500 curves counting a total of 46K vertices gets 1 offset in less than 100ms),
Able to provide 1 or more consecutive offsets which never break and always stays consistent.
My thought: GH2 should really implement Clipper2 tools by default. It is an incredibly powerful and versatile tool and it’s freely available, and yet so little considered from GH developers.
Confusingly enough Clipper 2 is by another author.
The original clipper addin by me ( food4rhino.com/en/app/clipper-grasshopper-and-rhino) seems to be two to three times as fast and does not show this error, any reason you need Clipper 2, rather than the original?
I’ve not updated this recently, but it’s mainly because it’s been stable for over quite some time (it’s also compatible with Rhino 8, I see that I need to update the food4rhino page).
Thanks Clipper for GH, it is a great tool for reliable offset. As a developer I now use Clipper 2 (indeed clipperZ !!), I think it is a bit more simple to use than Clipper 1. Also I try on my tool to stay with clipper path in order to limit the conversion.
I am not really sure of this. I use it a lot in Nautilus, PolyTree is a great tool to organize curves in order to bridge them for 3d printing. Cura slicer is using Clipper.
But YES clipper could be useful as native in Rhino/Grasshopper tool.
I’ve not explored or needed an upgrade, any noticable differences? (I’ve considered offering it as an upgrade option, but old stuff just needs to keep working)
Thanks for the discussion so far. In this specific case, Simplify Curve actually solved the issue, even though I was pretty sure I tried that too beforehand.
About the reason why I’m focusing Clipper 2, it was because the author of the libraries (AJ) stated that they evolved quite a lot and used more efficient algorithms and broader set of tools, so I supposed that applied to their ports too. I haven’t run exhaustive benchmarks between them, perhaps the particular implementation of this GH port made it slower. I need to check more closely the computation times.
What I was meaning, is that the options to benefit from it in GH are very limited. Currently there is the original repository from AJ that is being maintained, while in GH we have two options, one based on the “first generation”(by arendw), it works well, but has been superseded by the “second generation” but its implementation is not up to date and allegedly shown the issues discussed here. Also, in my case, it is missing referenced libraries which no one so far can address why and how. I just messed up with some common dlls and partially solved, but I still get errors every time I open GH and some components throw errors of this kind when used, and is very annoying.
About my solution, I think it still ended up in an useful tool and I’m renaming it Polyline Sequential Simplification. I am posting an update, now it works on polylines which are closed, open on a grafted list of mixed open and closed ones. It supports a threshold, and results in good simplification results considering it is non iterative. It focuses on removing “spikes” and performs also some kind of simplification when the treshold is increased, altough it is not a rigorous process such as in Douglas-Peucker.
It basically culls points which are too much far away from the line traced between its preceding and following vertex.
