Efficient chaining/batching of boolean operations

[awgil]

What is the recommended efficient way to perform multiple boolean operations? Several examples (using C# version 1 of the library):

1. Clip multiple subject polygons to one polygon. Currently every time I just call Clear() / AddPaths() - but this seems inefficient, since it discards everything done by AddPath for clip polygon... Is it possible to "partially clear" clipper, or add clip poly and clone clipper state?
2. Chain operations (e.g. union multiple polygons together, then subtract from another polygon, etc.). Currently I just execute each operation, Clear() and AddPath() result back into clipper - but this seems inefficient, since it converts internal representation into result, discards internal state and then converts back result from previous operation into internal state...
3. Specifically for union, documentation seems to imply that I can just call AddPaths repeatedly, adding multiple polygons as subjects, and then executing union once - but that doesn't seem to be correct... Imagine two situations - (1) union of larger and smaller (fully contained inside larger) square - two AddPaths() calls with 1 path each, expected result is equal to larger square, (2) union of "larger square with smaller square hole" and empty polygon - one AddPaths() call with 2 paths, another AddPaths() call with 0 paths - expected result is equal to first subject. However, looking at the code, this seems to result in the same internal state - in both cases there would be 2 AddPath() calls, for bigger and smaller square, and thus result is the same (as in situation 2, if using even-odd rule). Is this something that was redesigned in version 2 of the library?

[AngusJohnson]

What is the recommended efficient way to perform multiple boolean operations? Several examples (using C# version 1 of the library):

1. Clip multiple subject polygons to one polygon. Currently every time I just call Clear() / AddPaths() - but this seems inefficient, since it discards everything done by AddPath for clip polygon... Is it possible to "partially clear" clipper, or add clip poly and clone clipper state?

I can't really recall what happens in Clipper1 but I think it's the same as Clipper2, which is that you don't need to Clear() unless you are modifying input (subject & clip) paths. Just call Execute() again using the changed clipping op or fill rule.

2. Chain operations (e.g. union multiple polygons together, then subtract from another polygon, etc.). Currently I just execute each operation, Clear() and AddPath() result back into clipper - but this seems inefficient, since it converts internal representation into result, discards internal state and then converts back result from previous operation into internal state...

I'm lost 😱, and I have no idea what you're tring to achieve.

3. Specifically for union, documentation seems to imply that I can just call AddPaths repeatedly, adding multiple polygons as subjects, and then executing union once -

Yes, that should be identical to adding all the paths in a single call.

but that doesn't seem to be correct... Imagine two situations - (1) union of larger and smaller (fully contained inside larger) square - two AddPaths() calls with 1 path each, expected result is equal to larger square,

It all depends on the filling rule. For example, if you're using EvenOdd then no, you'll get a hole at the smaller path.

(2) union of "larger square with smaller square hole" and empty polygon - one AddPaths() call with 2 paths, another AddPaths() call with 0 paths - expected result is equal to first subject.

Huh? I'm lost again. Why are you adding empty polygons and what is a 'call with 0 paths'?

[awgil]

1. The clip/fill rule is the same (intersect/even-odd), but I have single clip polygon C, a large set of subject polygons Si, and want to calculate a set of clipped polygons Ri = Si (intersect) C. Since there is no 'remove path' API, currently for each i I do Clear() + AddPath(C, clip) + AddPath(Si, subj) - and this repeated AddPath(C) is an inefficiency I'm looking to remove.
2. Say I have polygons A, B, and C, and want to calculate "A (minus) (B (union) C)". Currently what I do is first calculate R = (B union C), then clear, then calculate (A minus R). The inefficiency here is that I first convert internal representation of R into result (Paths or PolyTree), then convert it back into internal representation by doing AddPath.
3. Imagine I have two 'square' paths - larger A (defined by points (2,2), (2,-2), (-2,-2), (-2,2)) and smaller B (defined by points (1,1), (1,-1), (-1,-1),(-1,1)). Then I could have two situations:
   3.1. Union of A and B - I can do that by adding A as subject, B as clip, and calling execute(ctUnion). The result is obviously same as A.
   3.2. The documentation seems to imply (see FAQ for clipper 1) that for union there is no distinction between 'clip' and 'subject' polygon - it says that if I have multiple polygons that I want to union together, I can just add them all as subjects). Yet if I do that (add both A and B as subject), calling execute(ctUnion, even-odd) returns a 'square with hole' polygon.
   3.3. From what I see in the code, if instead I had two other polygons - polygon C 'square with hole' (defined as Paths two elements, one equal to A and one equal to B) and polygon D 'empty' (defined as Paths with zero elements) - and were to add them both as subjects - that would result in identical internal state as in 3.2. But here the expected result is different - it should be equal to C.
   3.4. So, maybe I'm misunderstanding something - what is the correct way to calculate a union of multiple potentially overlapping polygons in a single call?

[alexisnaveros]

Just a side comment regarding point #1, it wouldn't actually be hard to implement a "remove path" function... Perhaps both AddPath() and AddPaths() could return a "handle" (pointer, ID, whatever) that allows easy removal of the path later by RemovePath( handle ).

You raise an interesting point with #2, how to keep the Vertex list between calls to minimize the overhead... But are you sure it's a bottleneck? There's really not that much processing there. And the list of local minima need to be rebuilt anyway.