algorithmic modeling for Rhino

As a collective can we find a way to overcome the pitfalls of the current inward offset of polylines? 

It keeps coming up time and again and it would seem that there is no solution with the current implementation of Offset as it is in Rhinocommon due to the user interaction element.

I have tried a few different ways to achieve this. My most successful attempts are attached. I call the project Robust Offset (but Kevin is just as good).

In the image below you will see three Offsetting routines of a simple Voronoi pattern. The top one being the native GH Offset Component (Fail). The middle is a Shortest Walk* and the bottom one is a Boundary Solid method (time consuming). If you start to increase the distance then both the SW and SB method will begin to breakdown but it seems to go longer than Native component and even though they are wrong they aren't wildly wrong.

The biggest hurdle to overcome is how to define the interior shape based only on the intersections of a collection of curves some making sense some not.

* you will need to download the component from

Views: 3912


Replies to This Discussion

hmmm.... maybe someone can implement this?

Looks really good... Glad someone else thinks we need to talk about this :)

I've been longing for that one for a while.

Limiting the problem to robust offsetting of voronoi cells makes it quite easy. It's solving all the 2d nurbs and concave shapes that scares me.

If it was that easy would the people at McNeel not have already done it? :)

I think that whilst Voronoi is subjected to ridicule here on the forum, much in the same vain as Gingas (rhymes with ringers) in the UK, it provides a good starting point as there are lots of examples in the one routine.

I started writing on a polyline offsetter myself when this thread was started, however Dale Lear in Seattle said he'd like to work on an improved offsetter so now I'm holding off for the time being. If nothing moves in a few months, I'll pick up where I left off.


David Rutten

This is good news

Hi David,

Has there been any progress on this?

If a man says he's going to do something he'll do it! There's no need to keep asking him every 3 years!



No, for GH1 I recommend using the Clipper plugin, I'm planning on adding the clipper code directly to GH2 so it is accessible natively.

Mmm...I've notice that the linked paper talks about poly-lines but, what about nurbs curves with self-intersection (the algorithm needs points where the polyline breaks to pre-process the geometry)? 

But let's start talk about the issue, that is very very important and it seams that we are starting in the right direction. 

I've been looking at offset issues for a while. The problem is certainly not trivial.

Even just for polygons it is quite complex as the topology of the offsetted line can change depending on the offset distance and the initial geometry - its angles, concavity, etc (ie, points/line segments 'disappear' when edges collapse in length as you move inwards)

Most algorithms require the calculation of the polygon straight skeleton (like the ridge lines on a pitched roof) in order to generate the offset line, and they use techniques with half-edge meshes (HEMs) or 'motorcycle graphs'.

There are a bunch of algorithms available (see links at bottom), however they are either very complex to implement or the computational geometry library that they are implemented in (eg, CGAL or Clipper) is inaccessible from GH. (As an aside, this may be another reason for some sort of access to CGAL??)

That is just for polygons, and I'm sure polylines/polycurves have their own complexities...






© 2022   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service