We need to talk about Offset

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 Food4Rhino.com

Attachments:

roboffset.gh, 67 KB

Replies to This Discussion

Permalink Reply by Andrew Heumann on June 16, 2014 at 8:19am

hmmm.... maybe someone can implement this? http://seant23.files.wordpress.com/2010/11/anoffsetalgorithm.pdf

Permalink Reply by Danny Boyes on June 16, 2014 at 8:45am

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

Permalink Reply by Ola Jaensson on June 16, 2014 at 9:25am

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.

Permalink Reply by Danny Boyes on June 16, 2014 at 9:46am

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.

Permalink Reply by David Rutten on June 16, 2014 at 11:41am

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

david@mcneel.com

Permalink Reply by Danny Boyes on June 16, 2014 at 1:46pm

This is good news

Permalink Reply by Siemen on June 9, 2017 at 9:59am

Hi David,

Has there been any progress on this?

Permalink Reply by martyn hogg on June 9, 2017 at 2:27pm

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!

Permalink Reply by Adam Kiss on December 9, 2017 at 5:54am

Permalink Reply by David Rutten on June 9, 2017 at 2:38pm

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.

Permalink Reply by Ángel Linares on June 16, 2014 at 9:11am

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.

Permalink Reply by Daniel Fink on June 16, 2014 at 9:12am

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...

Research/links:

http://en.wikipedia.org/wiki/Straight_skeleton

http://twak.blogspot.com.au/2009/10/skeleton-index-page.html

http://www.cosy.sbg.ac.at/~held/projects/sk/sk.html

http://compgeom.cs.uiuc.edu/~jeffe/open/skeleton.html