Clipper2 strange results from ctDifference

[Garry Wood]

Hi, thanks for the great projects, both Clipper and Image32.

I've been trying out Clipper2 and noticed a strange result in one of our unit tests which I'm not sure is a bug or something I'm doing wrong.

Basically if I try to obtain the difference of two identical squares (so both Subject and Clip have the same coordinates) the result says the difference is a line with just two points.

I separated it out of our unit tests and can reproduce it in the very simplified example below:

var
 Clip: TPaths;
 Subject: TPaths;
 Solution: TPaths;
begin
  SetLength(Clip,1);
  SetLength(Clip[0],4);
  Clip[0][0] := Point64(0, 0);
  Clip[0][1] := Point64(1000, 0);
  Clip[0][2] := Point64(1000, 1000);
  Clip[0][3] := Point64(0, 1000);

  SetLength(Subject,1);
  SetLength(Subject[0],4);
  Subject[0][0] := Point64(0, 0);
  Subject[0][1] := Point64(1000, 0);
  Subject[0][2] := Point64(1000, 1000);
  Subject[0][3] := Point64(0, 1000);

  Subject := ReversePaths(Subject);

  with TClipper.Create do
  try
    AddPaths(Subject, ptSubject);
    AddPaths(Clip, ptClip);
    Execute(ctDifference, frNonZero, Solution);
  finally
    Free;
  end;
end;

The Clip path looks like this:

(((0, 0), (1000, 0), (1000, 1000), (0, 1000)))

and this is the Subject path

(((0, 1000), (1000, 1000), (1000, 0), (0, 0)))

then the Solution is this

(((1000, 0), (1000, 1000)))

which I read as a line down the right hand edge that has no width (just two points).

If I run the same test with Clipper 6.4.2 (adjusted for the changes between versions) I get a solution that says there is no difference, as expected.

If I leave out the ReversePaths I get a different result (top and left edges basically) but still not the same as Clipper 6.4.2 which says no difference.

One other thing I noticed while testing, if I make the upper X value of the Clip path 1001 then the result says there are no differences.

Thanks in advance for any thoughts or info you can provide.

[Terence_13]

You got degenerate points between subject and object (=fully overlapping points). Apparently clipper and clipper2 cannot really deal very well with that. See also "bug report" I field here and response from Angus. Greiner-Hormann can easily deal with degeneracies, but got some minor other issues (e.g. you have to implement sweepline intersection search yourself if your are interested in similar performance to clipper, reference implementation is only available in C++, and you got to add UNION, DIFF XOR yourself to the code...all of which I found complicated and laborious to do, but did it anyway due to absolute must for correct clipping of degenerate polygons). I should also mention Prof. Kai Hormann was very supportive in helping out finding solutions to some algorithm shortcomings for some edge cases and is contemplating to further improve the algorithm once there are interested students.

[Ignorant]

Can I get more informan on Hormanns code ...I am playing around with some vatti family codes(after correcting them). I observed that they are basically polygon fill algorithms and that also are given in split forms. For odd even Angus clipper is NOT the most hip. Angus clipper is the most beautiful poetic code however, especially the gneration of incantations to derive the rendering commands in intersect edges.The 2 edges provide resolution upto 4 commands(2 actually if left/right sides are considered).The final resolution into the actual rendering step requires this incantation...I have been successful in NOT understanding that
Zero Area fills are allowed by all 3 libraries i had tried for Vatti....only clipper has code for flling other than odd even. A line segment is of area zero ..no..!!...