Update: now seems to work for at least 10k generators:

and a zoom-in of the same picture:

One way to compute 2D offsets for toolpath generation is via the voronoi diagram. This video shows the first (somehow) working implementation of my code, which is based on papers by Sugihara and Iri. Their 1992 paper is here: http://dx.doi.org/10.1109/5.163412, then a longer 50-page paper from 1994 here: http://dx.doi.org/10.1142/S0218195994000124, and then there's a more general description of the topology-based approach from 1999 here 10.1007/3-540-46632-0_36, and from 2000 here: http://dx.doi.org/10.1007/s004530010002

The algorithm works by incrementally constructing the diagram while adding the point-generators one by one. This initial configuration is used at the beginning:

The diagram will be correct if new generator points are placed inside the orange circle (this way we avoid edges that extend to infinity). Once about 500 randomly chosen points are added the diagram looks like this:

Because of floating-point errors it gets harder to construct the correct diagram when more and more points are added. My code now crashes at slightly more than 500 generators (due to an **assert()** that fails, not a segfault - yay!). It boils down to calculating the sign of a 4-by-4 determinant, which due to floating-point error goes wrong at some point. That's why the Sugihara-Iri algorithm is based on strictly preserving the correct topology of the diagram, and in fact they show in their papers that their algorithm doesn't crash when a random error is added to the determinant-calculations, and it even works (in some sense) when the determinant calculation is completely replaced by a random number generator. Their 1992 paper constructs the diagram for one million generators using 32-bit **float**

numbers, while my naive attempt using **double** here crashes after 535 points... some work to do still then!

CAM toolpaths tend to be based on CAD-geometry in the form of lines, circular arcs, or spline-curves and such. One way forward is to think of a curve as a lot of closely spaced points along the curve. There are also papers which describe how to extend the algorithm for line and arc generators. See the 1996 paper by Imai. There is FORTRAN code for this by Imai over here (I haven't looked at it or tried compiling it...). Held et al. describe voronoi diagram generation for points and lines in 2001: http://dx.doi.org/10.1016/S0925-7721(01)00003-7 and for points, lines, and arcs in 2009 http://dx.doi.org/10.1016/j.cad.2008.08.004. This pic from the Held&Huber 2009 paper shows point, line, and arc generators in bold-black, the associated voronoi-diagram as solid lines, and offsets as grey lines.

Held has more pictures here: http://www.cosy.sbg.ac.at/~held/projects/pocket_off/pocket.html

Note how within one voronoi-region the offset is determined by the associated generator (a line, point, or arc). It's very easy to figure out the offset within one region: points and arcs have circular offsets, while lines have line offsets. The complete offset path is a result of connecting the offset from one region with the next region.

Hi, I'm working on the incremental Voronoi in Flash, and have just reached the point at which I need to robustify everything. Your progress is inspiring, and the links are invaluable! Just making my way through the 50-page Sugihara-Iri paper now and reviewing my geometric primitives with Introduction to Geometric Computing in hand. Can't be returning NULL when asked for the circle through three points!

I'm not going for raw speed; it'll never approach that of native code anyway, and I'm trying to write it as clearly as I can.

Anyway, gambatte!

Hi Alan, I've just recently tried to refactor the code into a separate half-edge-datastructure and a separate voronoi-specific class.

The half-edge data structure is described e.g. here:

http://www.holmes3d.net/graphics/dcel/

my preliminary code is here:

http://code.google.com/p/opencamlib/source/browse/trunk/src/algo/halfedgediagram.h

I'd like to template the half-edge class on the vertex/edge/face property classes so it can also be used for delaunay-triangulations and other adaptive meshes/cl-surfaces I will need for my CAM-coding efforts...

let us know where your code is and if there's going to be a web/flash demo somewhere!

AW