Hi,
We've come across a simple set of inputs for the Union operation which do not seem to give the correct result. Here are the inputs formatted for the C++ clipper_console_demo.exe:
subj.txt:
4, 1
3, 1
3, 0
4, 0
clip.txt:
5, 2
0, 2
0, 1
5, 1
2, 1
1, 1
1, 0
2, 0
Command line:
clipper_console_demo subj.txt clip.txt UNION NONZERO NONZERO 0 100
The two smaller squares (one in subj.txt, one in clip.txt) are both abutting the larger rectangle from clip.txt, so the result should be a single polygon. However the smaller square from clip.txt does not get unioned, as you can see in the svg result (two shapes):
path d=" M 410.00 10.00 L 410.00 110.00 L 510.00 110.00 L 510.00 210.00 L 10.00 210.00 L 10.00 110.00 L 310.00 110.00 L 310.00 10.00 z M 210.00 110.00 L 110.00 110.00 L 110.00 10.00 L 210.00 10.00 z"
If you run the command with the subj.txt and clip.txt swapped, you get a single result shape, which is expected:
path d=" M 210.00 10.00 L 210.00 110.00 L 310.00 110.00 L 310.00 10.00 L 410.00 10.00 L 410.00 110.00 L 510.00 110.00 L 510.00 210.00 L 10.00 210.00 L 10.00 110.00 L 110.00 110.00 L 110.00 10.00 z"
I was able to reproduce this with the C# console demo and the javascript port (http://jsclipper.sourceforge.net/6.2.1.0/main_demo.html), though with those versions I the original subject/clip inputs worked fine, but swapping them resulted in two output shapes.
Not sure if this is a real issue or user error?
In any case, thanks very much for all your work on Clipper!
Best Regards,
Duncan
Anonymous
Hi Duncan. This isn't a bug because there's no guarantee (in the documentation) that common edges in solutions will be joined. This is something I'm addressing in Clipper2 that's progressing but still a way off.
Hi Angus,
Understood, and thanks very much for the quick response.
I had the thought that if I could detect that the result had abutting polygons, I could try re-running the union on the output shapes, maybe with order swapped. I see in Clipper::JoinCommonEdges() the code:
I hit that 'continue' when I get two output shapes, and it does not get hit if I change the input order and a single output shape is returned. Do you think it makes sense to report that there was a join failure in some way (maybe just setting a boolean m_couldNotJoinOputShapes=true, or someting)? Or are there cases where you could have abutted output shapes, which cannot be detected?
Thanks and Best Regards,
Duncan