Shrinkwrap, but for curves? (more robust but less accurate _offsetcurve?)

_offsetcurve is buggy.

it produces buggy results often enough that relying on it in a grasshopper definition that uses anything but the simplest curves means accepting that the definition may lose some robustness.

There are a bunch of threads on this forum lamenting this at length and also looking, unsuccessfully, for better solutions, also at length.

My question is: if Rhino 8 can give us a much more robust but slightly less precise alternative to offsetting a polysurface by converting it into a fine mesh and running some fancy new code in the Shrinkwrap command, why can’t we have a command that does something similar, but for curves?

How about a single command that converts a curve to a fine polyline and offsets it robustly, though not with perfect accuracy to the original?

Why could that not also be done in a way that converts the polyline back to a curve by rebuilding it to within a user specified tolerance?

And while I’m here: is Rhino’s offsetcurve code uniquely quirky? Does Solidworks or Fusion have the same kinds of occasional buggy results? Is there some insurmountable math here or is getting better results from offsetcurve just a matter of putting more dev time into it?



I’ve been poking around in offset quite a bit lately to help return multiple curves when an offset curve intersects itself. Here’s the specific issue. I’m hoping to have it turned on in the WIP here soon.


The results are a bit more dramatic with OffsetMultiple



These changes should ripple out through the rest of Rhino that rely on offsetting a curve. This would also include curve offsets in Grasshopper but I haven’t checked yet.

What other problems are you having with curve offsets? I know polyline offsets can sometimes be a little strange (I’m hoping to also take a stab at this in the near future).


The problem I have is pretty simple, every once in a while, I get nonsensical results.

Just often enough for GH definitions working with fonts to be too unreliable to trust for mass-processing text.

Attached is a simple definition that offsets curves derived from text objects input in surface form (I use surfaces as input because it guarantees the directions of interior borders will be flipped, thus making the directions of the offset curves robust)
offset (441.4 KB)

I’ve repeatedly run into this issue with fonts. I’d suggest using the whole alphabet, typed out in upper and lowercase, in various fonts as a method of testing your new offset algorithms, because the diversity of form is very wide with fonts, and because they’re a multi-variable curvy thing that lots of people need to work in in the real world.

In the definition I attached, the fonts don’t have any curve structure weirdness or faults, no self intersection or open curves. This is another reason I use the surface option when creating text objects to use for testing.

I am very glad to see what you’re up to. It’s one of the problems I run into, and it seems solved, which is great news.

I find that the linework on fonts are almost always garbage and I would never use them “as is” as input curves. More often than not they have duplicate points, kinks, overly complicated curves and tiny segments - even on commercial fonts. I don’t think any amount of programming on Offset will ever make up for the laziness and carelessness of typography designers. It’s just like every other operation in Rhino: garbage in, garbage out.

1 Like

I have a bunch of GH clusters that I use to clean fonts up before processing. Before I run curves through the offset component, I’ve already removed self-intersections, changed segments that are curved but very nearly straight into truly straight segments, removed disproportionately tiny segments, and rebuilt curved segments that have certain discontinuities.

The examples I used above are on the cleaner side. There’s still a capital B that becomes something the shape of a tiny Starfleet badge after being offset, and some other quirks.

Generally, I find that rhino’s off the shelf fonts perform pretty well, as long as I derive curves from the borders of text created as surfaces.

Also it’s not just fonts. There are whole threads on this topic with some of the best contributors on this forum giving it a try.

see also: Offset madness

1 Like

That’s amazing!
It’s long time we’re waiting for this.

It would be “retrofitted” to v7 as well? I hope so…

1 Like

Hi @Max3
Sounds like quite the setup - I rest my case! But I have to ask about the link, which sends me to Oakland; is there a hidden meaning or was it just the wrong link? :grinning:

1 Like

I think it’s just a matter of priorities and man hours…

dear @Joshua_Kennedy
this looks great and promising especially for machine path generation.
there is a lot of papers out there, how to generate offsets that are also optimised for HSC (High speed cutting).

From my perspective it would be fantastic, If there would be an option to allow some absolute tolerance to get less sharp corners inwards - with circular / smooth style.

and please make it available in the API / Rhinocommon.



yeah I was having a discussion with somebody about the ugliest park we could thing of, and apparently I sent that link instead of this one: We need to talk about Offset

(repaired above)

1 Like

It’d be awesome if we could get some more features usable for toolpathing.

What would be truly truly amazeballs is if McNeel could find a way to buy MecSoft and fully integrate RhinoCAM, Rhino, and Grasshopper, creating a product that could eat a lot of autodesk marketshare.

1 Like

Hi Joshua,

I’m designing climbing walls and volumes for climbing walls in Rhino with Grasshopper. One of the tasks is to generate a hole pattern and the pattern is generally a series of offsets of a face boundary.

I used to create the offsets with native Grasshopper components but then at some point found the Clipper plugin which results in clean offsets with much less fiddling. In the screenshot above, you can see one boundary of a face of a volume and the offsets I did manually in Rhino 7 on the left and two Grasshopper approaches (native + Clipper). Creating the offsets manually, depending on which segment I selected, the third offset fails. I’m fine using Clipper right now but if this was possible with native components and without having to test the output and cull invalid / unwanted curves then I’d happily move back to native compnents.

Below is a Rhino file with one face boundary curve and its offsets and a Grasshopper definition with a native approach and offsets created with Clipper:

offset_problem.3dm (58.8 KB) (25.9 KB)


Sorry but probably not. This is a complete overhaul of how Rhino trims the offset curves and isn’t a small bug fix that can be ported back to V7.

That sounds like this issue but I’m not sure. If not I’ll add your request to the pile. I don’t have any plans to start working on offsets optimized for high speed cutting.

These updates should work on the existing offset functions.

Thanks for the examples. I added them to my list for testing. So far it seems to get the right answer.


Good off-in job!



thanks for having a look at this.
there is a lot of nice papers about offseting curves for milling / pocketing - this is one reason why i pointed out at this.

My suggestion / idea was more to have a tolerance, that would allow filleting / smoothing to the inner curves.
Let s say the offset is 10mm, and the tolarance 1mm - the first curve can be filleted by 1mm, the second by 2mm and so on…

Highspeed Cutting is one application, but also very cheap hobby milling machines profit from approaches similar to this - allowing better acceleration / less vibration and no stops, burnings and so on in the corners - resulting in longer lifetime of the mill-bit…

for me this is a nice to have - but no must.

1 Like

agree. this is already part of the ribbon offset command, and there are many circumstances, such as 2 rail sweeps, where being able to smooth a part of an interior offet curve that’s resulted in a sharp point would be very useful both in Rhino and Grasshopper.

Hey @Joshua_Kennedy, you’ve been working on all the best goodies for V8, haven’t you? :wink:

I am working on the case below, which, with the absence of a good offset algorithm requires lots of grasshopper cleanup (and/ or a region union that is computationally heavy).

With Clipper:

With Pufferfish:

Might also be a good test case for your curve offset.
Offset (25.9 KB)

E: By the way, is there any ETA for when this comes to Grasshopper in the WIP? Could really really use it right now. :innocent: