Open bacchanalia opened 5 years ago
This may be related to https://github.com/kuribas/cubicbezier/issues/6 . I know there was another similar example where reversing one of the paths involved caused it to work --- does this example exhibit the same behavior?
neither d or (circle 2) reversed
d reversed
(circle 2) reversed
both d and (circle 2) reversed
Weird!
The way paths are converted to be used with cubicbezier
package leads to a tiny segment. I think this tiny segment (straight (V2 (-0.0) 4.440892098500626e-16)
) is not handled well by cubicbezier
. Boolean operations on non-convex polygons is super hard to get right in all the strange cases. This only gets harder with cubic segments. We could filter out tiny segments before handing off to cubicbezier
.
What was the reason you switched to the "overlap" version again?
I didn't switch back to the overlap version. I just figured: see weird behaviour, post weird behaviour. I ended up not using binary operations anyway because of the union of difference bug I hit, and instead went with slicing up my diagram at intersections.
I just figured: see weird behaviour, post weird behaviour.
Absolutely! I just was wondering if there was a need for that particular overlapped form in your workflow.
In the following code ex4 unexpectedly produces an empty diagram.