Ignorant

does version 2 release handle overlapped output polygons in the result?.

The algorithms depend on intersections and render /fill by a advancing scan line. FOR Clipper even within a scan beam the rendering proceeds with a scan line provided by the y coordinates of edge - edge intersection points, Where is this assertion tested and how is it reported back to the callee? I am curious only for odd-even fills of closed input polygons.

Do I Understand that for the XOR operation all edges are HOT (i.e. have a attached output contour) only for odd even.?. I never played with other windings.

Sorry, I dont know how to use gmail properly.I will be careful when i use the reply option.!

Jay, I got hold of a original release announcement for the general polygon clipper..very old ..got it from wayback archives. It says multiple polygons are allowed on either side only if they are disjoint in the subject group and clip group. for gpc. In the XOR operation it shows some unexpected behaviour if edges within a beam are bundled.(Murta transform of edges). The XOR was introduced in the vatti family by MURTA with his Generic Polygon Clipper. I have edit his version 2.32 and 2.33(later withdrawn!)...

Well, I am just playing with a odd even rule based old program.The output shows intersections. And I thought Doinga union might help. The union can be done over the filled regions in each polygon. no.?. On Mon, Dec 20, 2021 at 4:44 PM Jay Tee jay-tee@users.sourceforge.net wrote:

Well ,without forming edge bundles all intersections in XOR are contributing and most of the render commands are just as in Vatti and specifically same as in clipper. (I am using a relic version . ) I am exporing the XOR clipping for odd even when NOT all murta edges are contributing.! .And the splitting the render commands using the 4 Quadrants by Angus recipe fails. I found the XOR the simplest so I am exploring that.. On Thu, Feb 24, 2022 at 8:13 PM Jay Tee jay-tee@users.sourceforge.net wrote:...