daef / poly-bool-comparison Goto Github PK

Hi. The result image links are broken.

For example, one of them looks like this: https://daef.github.io/poly-bool-comparison/magick///daef.github.io/poly-bool-comparison/rust-geo-booleanop/pngs/twointersectingcontours_tri3_X.png
But it should probably be: https://daef.github.io/poly-bool-comparison/rust-geo-booleanop/pngs/twointersectingcontours_tri3_X.png

I noticed that currently the SVGs don't specify a fill-rule, which means that they default to a nonzero fill rule (i.e., winding order matters). Some thoughts:

• I'm not sure if Martinez implementations actually care about winding order. They most likely ignore it at the input and input is rather interpreted in "evenodd" semantics. As for the output I haven't put any effort (or tests) into rust-geo-booleanop to guarantee correct winding order; all tests seem to assume evenodd semantics. So in general you may see better results using evenodd semantics.
• It looks like the input data itself does not follow the nonzero winding rule properly. How have the pngs of foo and twointersectingcontours been generated? It seems using "evenodd" fill rule is necessary to obtain them. This inconsistency leads to some wrong results: For instance, rust-geo-booleanop has an optimization when performing a union operation with an empty polygon: It returns the other polygon as is. Currently this shows a wrong result, because the input polygon gets converted wrongly.

Depending on what you want to achieve (testing for correctness w.r.t. evenodd or nonzero rules) you may either fix the input polygons or change the SVG conversion to evenodd. This can be done by changing line 9 of svg.js to:

w('<path style="fill:#000000" fill-rule="evenodd" d="')

This fixes a lot of "false negatives" for me as shown here: 21re/rust-geo-booleanop#15

Just wondering, but why does holes have the ending points; [0,1], [0,0]

[
    [ [0,0], [1,0], [0.5,1], [0,0], [0,1], [0,0] ], // <----
    [ [0.2,0.2], [0.5,0.8], [0.8,0.2], [0.2,0.2] ]
]

Thank you for your project, I think its a very good way of benchmarking the algorithms.
There is a wasm version of skia's path algorithms (https://skia.org/docs/user/modules/pathkit/)
which includes boolean operations.
I think it would be very interesting to see how the leading 2d library performs in this test.
I could try to implement this, but if you would want to include it I think you would be more efficient in doing this.
Please let me know what you think.

FYI, this polygon definition is rotating clockwise about Z, which I believe is wrong.

FYI, this polygon definition is rotating clockwise about Z, which I believe is wrong.

How about changing the color of BAD results to gray or white?

It's impossible to see the results with BLACK backgrounds.