polybool function works wrong

Looks like the polybool function can give completely wrong results in some cases. The simplest example is the following:

p1x = [-0.38638747761632497000 0.19712615255652799000 0.11632212129588278000];
p1y = [-0.19990841690264510000 0.44255449769997601000 -0.32295394513363201000];
p2x = [-0.63774227707713371000 0.09164976063543484000 0.61903172020561337000];
p2y = [-0.13838565278600026000 0.66469299048631436000 -0.44599947336401247000];

[p3x p3y] = polybool('-', p1x,p1y, p2x, p2y);

figure;
hold on
plot(p1x([1:end 1]), p1y([1:end 1]), 'o-black')
plot(p2x([1:end 1]), p2y([1:end 1]), '.-g')
plot(p3x([1:end 1]), p3y([1:end 1]), '*-r')

Here the subtranction should give empty polygon, while it gives something strange (see red polygon)...

So the question is: are there any alternatives for polybool function for subtracting and merging polygons?

Answer 1

[Kelly Kearney]

I see the correct empty result in R2015a, but the same not-quite-right results that I assume the original poster was seeing when I try the example in R2013a.

So if you have the option of updating to R2015a, try that first. Otherwise, you might try looking at these options on the FEX: Polygon Clipper (which uses the same underlying GPC library as polybool, or Polygon Clipping and Offsetting, which uses a different mexed library.

Answer 2

[Nalini Vishnoi]

Hi Dmitry,

Which version of MATLAB are you currently using? I tried the sample code in MATLAB R2013b (and later versions) and it returned p3x and p3y as empty arrays (which is the expected answer). However, it looks like there was some issue with versions between R2009b and R2013a and the sample code returns unexpected results of polybool subtraction in these versions. Again, the versions before R2009b (R2009a and earlier) return the correct expected result.

Please try the sample code on a recent version of MATLAB and confirm this.

Thanks, Nalini

Answer 3

[Dmitry]

I am using R2012a. I will try a newer version.

Answer 4

[Dmitry]

OK, I switched to R2015a and the problem seems to be gone. However, with R2015a the following polygons are not processed correctly (resulting in error in mex-file) :

p1x=[    399.023531681327e-003    96.9934488865085e-003   -46.1199124451526e-003   ];
p1y=[   -31.9883291050408e-003   -301.555280995922e-003    267.345679958538e-003  ];
p2x = [   -46.1199124368122e-003    399.023531682080e-003    96.9934488865085e-003      -205.036633882074e-003   -46.1199124375366e-003   -46.1199124368122e-003];
p2y = [    267.345679952930e-003   -31.9883291055476e-003   -301.555280995922e-003    -571.122232863033e-003    267.345679953417e-003    267.345679952930e-003];

I guess this is due to the fact that some points are repeated twice. But this code works in R2012a!

[Kelly Kearney]

Interesting. The problem definitely seems to be due to the duplicated point. My license for 2012a isn't valid anymore, so I can't test that, but the code for polybool.m doesn't appear to have changed at all between the two versions, nor does any of the code in the setup subfunctions ( checkxy.m, vectorsToGPC.m, etc). However, the gpcmex file itself seems significantly smaller in 2012a than in 2015a, so something must have changed under the hood there.

Are these examples you're posting typical ones for your application? Because they seem to be pushing the limits of polygon clipping algorithms. Perhaps adding filters to check for and remove unnecessary duplicated vertices will help. If these are typical input data, though, you might want to rethink your overall algorithm.