Cutline Holes / mono Polygon in Clipper2

[MCVenor]

Hi dear Clippers,

first, thank you Angus Johnson for providing this great Code, it truly helps out a ton!
(if only i knew earlier about it, i could save some serious reinveting time!)

second, i tried searching this question in issues and discussions but it apears that i am unlucky. Should there be one, please point me to it.

Is there a way for me to get a "mono Polygon" ?
Or in other words, "cutline holes" with clipper?

image from : godotengine/godot-proposals#913

I have found this on the Stack
and basically i want to get that Red Crossed result.

Sofar i have looked long into the documentation and couldnt find anything, the only thing that came close was EndType.Butt but this isnt an option for clipping.
I also tried to manually "merge" the paths together, and this works for simple "1 hole" tests:

But the planed usecase is to have an unknown amount of holes. (here is one with 9)

So i was wondering, is there a way for me to get this kind of result from Clipper?

(if not, i will try to come up with some sort of path concatenation shenanigans, any pointers would be welcome)

[philstopford]

No - you'll need to write your own keyholing code. I have done this in my personal stuff (https://github.com/philstopford/DesignLibs_GPL/). It can be quite complicated.

In general, I work with floating point coordinates, so in the case of the keyholing I scale up the geometry to where scaling back down again will shrink the injected keyhole to a zero-impact edge. Having scaled up the input geometry:

• Iterate across each hole, casting rays outwards based on the normal.
• I tag the rays with their originating 'hole' number using the Z coordinate.
• Cut the rays using all other geometry (outer and other holes), and here I use the Z callback. Here, you need to carefully set and later check the Z coordinate because it can be that a ray is chopped by passing over another hole (which will affect the Z coordinate via your callback)
• Find the minimal length candidate ray that has one of its Z coordinates matching your hole ID.
• Offset that candidate by a minimal amount that will allow rounding when scaling back down later to have no impact (i.e. the offset, when scaled down, will fall below the rounding value of 0.5)
• Use that offset cutter along with all other cutters to difference the outer.
• Re-evaluate the output from the difference and iterate until no holes are present in the solution.
• Scale down the solution again.

Note that you may need to play a little with the approach to ensure overlap of line ends past the outer, otherwise the attempt to cut may fail.

It was a fair amount of work to come up with something and you also have to be careful to note that the zero-width keyholes will disappear if you run the scaled-down solution through a clipping operation again, which means you need to defer scaling down until you are likely done with any other clipping operation, or accept repeated re-checks in case the keyholes were eliminated.

[MCVenor]

@philstopford thank you for the awnser.

"No"
Ah, thats a bummer, but i suspected that already. Also thank you for clarification and some ideas on how to achive it still.
I will come up with something, i might actually have an idea already.
Short: If everything is a closed path, and no paths intersect another, i can just keep punching holes and it should be impossible to "break" the polygon.

[philstopford]

Clipper will always render fully enclosed holes as a reverse winding path from the outer in which they are contained. I'm not sure that's understood from your reply. You will need to connect these holes to your outer geometry. This can be also a really interesting problem when you consider recursive holes - that is to say that you have an outer which fully encloses a hole, which itself fully contains an outer and optionally another hole.

A naive approach will miss the internal island and lose it (because the different of the outer with all holes + connection will drop the covered outer. It's really quite an interesting problem to solve in the end.

[MCVenor]

Well, i have a working solution.
And as long as this "polygon 'holes' will always wind in a negative direction (in both Paths64 and in PolyTree64)" stays true, its all good.

The requirements are:

• 1 Outer closed path
• X amount of closed paths as holes
• Nothing is allowed to intersect anything

(number are the Cuts, red lines)
And should the full "path" ever wind in a strange way, i could always just reStraight it with some angle measurement algorithm.

About the island you mentioned, i cant rly add anything informative to that. In the current project there is no situation where island could occur. The player could force an "island" but those would turn into own polygons immidieatly.

Thank you for the insights @philstopford .

[AngusJohnson]

#820 (comment)