unity-delaunay VS kurbo

I wrote a moderately popular Delaunay/Voronoi library for Unity a few years back [1] with a neat little demo video [2]. I implemented the incremental Bowyer-Watson algorithm for generating the triangulations, and then took the dual to generate the Voronoi tesselation (I also added a "clipper" that clips the voronoi diagram to a convex outline, which was fun, I haven't seen that anywhere else before and had to figure out how to do it myself).

Bowyer-Watson (which is described in this article) seems very simple to implement when you start: just start with a "big triangle" and then add points iteratively to it, and perform the flips you need to do. To do it performant, you have to build up a tree structure as you go, but it's not very tricky.

However: almost every description and implementation of Bowyer-Watson I could find was wrong. There's an incredibly subtle and hard to deal with issue with the algorithm, which is the initial "big triangle". Most people who implement it (and indeed I did the same initally) just make the triangle big enough to contain all the points, but that's enough: it needs to be big enough to contain all the points in all the circumcircles of the triangles. These circumcircles can get ENORMOUS: in the limit of three points on a line, it's an infinite half-plane. Even if they aren't literally collinear, just close, the triangle becomes way to huge to deal with.

The answer is that you have to put the points "at infinity", which is a very weird concept. Basically, you have to have special rules for these points when doing comparisons, it's really tricky and very hard to get right.

If I were doing this again, I wouldn't use Bowyer-Watson, this subtlety is too tricky and hard to get right. Fortune's sweep-line is more complex on the surface, but that's the one I would go with. Or the 3D convex hull technique (which I also wrote a library for, by the way [3]).

[1]: https://github.com/OskarSigvardsson/unity-delaunay

[2]: https://www.youtube.com/watch?v=f3T5jtsokz8

[3]: https://github.com/OskarSigvardsson/unity-quickhull

Fortunately for me, the internet came in clutch with the Oskar Sigvardsson Delaunay Unity Library with the vast majority of the work done for me!

Here's a link for the destruction use i mentioned: https://github.com/OskarSigvardsson/unity-delaunay

The numerical robustness thing gave me a chuckle (rotate 1 radian and pray to the geometry gods), especially as I've been spending a good fraction of my time dealing with that in fancy path rendering and stroking.

One of the things I really want to work on in the next few months is a path intersection implementation that's robust by construction, backed up both by a convincing (if not formal) argument and tests crafted to shake out robustness issues. I have a bunch of ideas, largely motivated by the need to generalize well to curves - Shewchuk's work, cited elsethread, is impressive but I'm not smart enough to figure out how to make it work for arbitrary Béziers.

There's an issue[277] to track the work, and that has pointers to some of the ideas. If anyone is interested in working with me on this, please get in touch. If successful, I think it'll result in a nice code base and also likely a publishable paper.

[277]: https://github.com/linebender/kurbo/issues/277

I have some ideas on how to do boolean ops, some of which is written up in a blog post issue, and for which I have some code locally. In particular, the parabola estimate seems much more efficient than the usual fat line approach. I also have a sketch of quadratic/quadratic intersection in kurbo#230.

I love these kinds of things and use them in GPU programming, among other things. Things have changed in a variety of ways: population count and count-trailing-zeros are generally available as fast instructions now. Multiply is also now just as fast as other operations, so is not to be avoided.

A couple examples. [1] computes the sum of the number of bytes used of four consecutive segments of a bezier path - each segment can be lineto, quadto, or curveto, can be the end of a path or not, and be i16 or f32. 4 tag bytes are packed into a 32 bit word, it computes all these, then sums them together.

[2] linearizes a recursive subdivision into an iterative loop. The stack depth is represented as the number of zeros in a word, so pushing the stack is a left shift, and popping is a right shift. It turns out you want to pop multiple levels at once, and the number of levels is computed by countTrailingZeros. ([2] is experimental Rust code, but I will adapt this into a compute shader)

[1]: https://github.com/linebender/piet-gpu/blob/main/piet-wgsl/s...

[2]: https://github.com/linebender/kurbo/blob/euler/src/euler.rs#...

That's a reasonable choice and I do agree it has nice properties, for example (a << b) << c is equal to a << (b + c) (unless that latter addition overflows), but it also does put you pretty firmly in the category of "not squeezing out every last cycle like you can in C." Usually that's one of the the things people expect in a tradeoff involving safety.

Regarding "never," I am an adventurous programmer[1], so am fully willing to accept that I am the exception that proves the rule.

On the more general point of UB for arithmetic overflow, I think we're on the same side: this is a pretty broken story in the way C has ended up, and one of the clear motivations for a cleaned up better-than-C language. I'm more interested in your thoughts on data races, where I suspect we have a substantive difference in perspective.

[1]: https://github.com/linebender/kurbo/blob/de52170e084cf658a2a...