Phil Stopford

Clipper2Lib issues should probably go to Github.

The scale is essentially what controls the error that you see. The larger the scale you use, the less error should be observed. I tend to scale by 1E4 or more, and because I wanted accuracy more than anything else, I tend to use doubles rather than floats. You will see the range of error if you review the returned values from Clipper; you're simply shifting the decimal point when scaling down.

To be clearer, ClipperLib works with integers. You'll need to scale up your geometry so that the minimum resolution sits on an integer interval (e.g. if you need to represent 0.001, you'll need to scale all of your geometry by at least 1000). You can then use this scaled geometry with ClipperLib and scale the result back down again afterwards. The main reason for this is to avoid errors from floating point precision.

Certainly looks cleaner to me. One other point I wanted to ask about - you have lowercase x/y in PointD and uppercase in Point64. Was that intentional?

Would you be persuaded to make the keyholing available, or is that dependent on the triangulation?

I wasn't sure if that would work as that might be misunderstood as comparing objects.

I was curious whether the triangulation / keyholing code was going to be progressed and eventually see C# form. The sandbox seems to not have this code any more, so I wanted to ask in case it had been dropped.

I have this locally as a way to get Bounds from any paths. It's useful where I just want to query extents without a Boolean public static Rect64 GetBounds(Paths paths) { int i = 0, cnt = paths.Count; while (i < cnt && paths[i].Count == 0) { i++; } if (i == cnt) { return new Rect64(0, 0, 0, 0); } Rect64 result = new() { left = paths[i][0].X }; result.right = result.left; result.top = paths[i][0].Y; result.bottom = result.top; for (; i < cnt; i++) for (int j = 0; j < paths[i].Count; j++) { if (paths[i][j].X...