[wip] Search the hull, too.

[mbostock]

TODO

• Decide if we want to rename voronoi.index to voronoi.inside?
• Don’t precompute the vectors; compute them lazily using the outside index?
• Clean up the duplicate distance checks in voronoi.find.

[mbostock]

I don’t like this solution… It feels surprising that voronoi.edges only contains information about the interior edges and omits the exterior (hull) edges.

For an interior (non-hull) point i, we currently store the sequence of neighbor points participating triangles [t0, t1, t2, …] in voronoi.edges.slice(voronoi.index[i * 2], voronoi.index[i * 2 + 1]). But for an exterior (hull) point, we don’t include the previous and next neighbor triangles on the hull in voronoi.edges—hence these neighbors triangles are not considered in voronoi.find.

Could we include the hull neighbors triangles for hull points, too? I’m imagining that for an interior point, the neighbors triangles would be a closed ring [t0, t1, t2, …, t0]. Whereas for an exterior point, it would be open, with the first and last neighbors triangles representing the hull edges.

This could potentially obviate the need for voronoi.vectors, since you could quickly check whether a cell is exterior by checking if voronoi.edges[voronoi.index[i * 2]] === voronoi.edges[voronoi.index[i * 2 + 1]]; that condition is only true for interior cells. Then we could compute the rays lazily since it’s just the perp vector of the corresponding hull edge.

Does that sound promising, @mourner? I’m not sure I’ve totally grokked the traversal algorithm you wrote for constructing voronoi.edges, but hopefully I can figure out how to modify it…

Edit: I was mistakenly referring to voronoi.edges as containing point indexes, when it contains triangle indexes.

[mbostock]

Thinking some more… I think the state of voronoi.edges is fine, it’s just that voronoi.find is wrong because it’s only checking one point per triangle in voronoi.edges, but for a hull triangle, it needs to check two points.