Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

union does not produce expected result when endpoints of a polygon overlap #77

Open
bacchanalia opened this issue Feb 25, 2019 · 6 comments

Comments

@bacchanalia
Copy link

In the following code ex4 unexpectedly produces an empty diagram.

{-# LANGUAGE TypeFamilies, FlexibleContexts #-}
import Diagrams.Prelude
import Diagrams.Backend.Cairo.CmdLine
import Diagrams.TwoD.Polygons
import qualified Diagrams.TwoD.Path.Boolean as B

rose n r1 r2 = polygon $ with
  & polyType   .~ PolyPolar (replicate n $ 1/8 @@ turn) (cycle [r1, r2])
  & polyOrient .~ NoOrient

roseWithNoOverlap = rose 7
roseWithOverlap   = rose 8

roseWithNoOverlapOrthoginal = roseWithNoOverlap 3 1
roseWithNoOverlapDiagonal   = roseWithNoOverlap 1 3
roseWithOverlapOrthoginal   = roseWithOverlap   3 1
roseWithOverlapDiagonal     = roseWithOverlap   1 3

ex d = stroke $ B.union Winding $ d <> circle 2

ex1, ex2, ex3, ex4, dia :: Diagram Cairo
ex1 = ex roseWithNoOverlapOrthoginal  -- works
ex2 = ex roseWithNoOverlapDiagonal    -- works: equiv to (ex1 # rotate (1/8 @@ turn))
ex3 = ex roseWithOverlapOrthoginal    -- works: equiv to ex1
ex4 = ex roseWithOverlapDiagonal      -- broken: produces nothing, expected quiv to ex2

dia = (ex1 ||| ex2) === (ex3 ||| ex4)
main = mainWith dia
@bacchanalia bacchanalia changed the title union does not produce expeced result when endpoints of a polygon overlap union does not produce expected result when endpoints of a polygon overlap Feb 25, 2019
@byorgey
Copy link
Member

byorgey commented Mar 8, 2019

This may be related to kuribas/cubicbezier#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?

@bacchanalia
Copy link
Author

neither d or (circle 2) reversed
neither
d reversed
d
(circle 2) reversed
circle
both d and (circle 2) reversed
both

@byorgey
Copy link
Member

byorgey commented Mar 9, 2019

Weird!

@fryguybob
Copy link
Member

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?

@bacchanalia
Copy link
Author

bacchanalia commented Mar 9, 2019

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.

@fryguybob
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants