You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that if a polygon has clockwise orientation and is "black" (not a hole nested inside another polygon), after it is sent through a union operation, it returns with the orientation flipped to counter-clockwise.
importpyclipperpc=pyclipper.Pyclipper()
# polygon has clockwise orientationpc.AddPath(((194, 510), (322, 0), (66, 0)), pyclipper.PT_SUBJECT)
solution=pc.Execute(pyclipper.CT_UNION)
print(solution)
# returned polygon has counter-clockwise orientation# [[[194, 510], [66, 0], [322, 0]]]# same result hereprint(pyclipper.SimplifyPolygon(((194, 510), (322, 0), (66, 0))))
The example above only has one subject path so does nothing, but it's enough to show the problem.
It looks like clipper "normalizes" the orientation to counter-clockwise for such polygons.
Is this the way it's supposed to be?
Most users probably won't care since it doesn't change the appearance of the resulting polygon (it's filled in both cases), but in the context of font editing software where some glyphs (letterforms) can be reused as "components" or references inside other glyphs, then the path orientation matters. Because, when two components overlap with each other, it's the path orientation of the "base" glyphs that determines the way such "composite" glyphs will be rendered (e.g. a single black shape, or with cuts and holes).
The text was updated successfully, but these errors were encountered:
This definitely makes a difference to my use-case (geomeppy), matching and intersecting surfaces in building simulation models. In the simulation models I'm targeting, there is a defined inside and outside surface of a polygon depending on whether the points are clockwise or counterclockwise. I already normalise all surfaces with this in mind, but wanted to point out another use-case where orientation matters.
Clipper is simply fixing the orientation of your outer boundary. See the documentation in ClipperLib for 'Orientation'. In computational geometry, polygons have a orientation, and algorithms make assumptions about the orientation.
Hello,
I noticed that if a polygon has clockwise orientation and is "black" (not a hole nested inside another polygon), after it is sent through a union operation, it returns with the orientation flipped to counter-clockwise.
The example above only has one subject path so does nothing, but it's enough to show the problem.
It looks like clipper "normalizes" the orientation to counter-clockwise for such polygons.
Is this the way it's supposed to be?
Most users probably won't care since it doesn't change the appearance of the resulting polygon (it's filled in both cases), but in the context of font editing software where some glyphs (letterforms) can be reused as "components" or references inside other glyphs, then the path orientation matters. Because, when two components overlap with each other, it's the path orientation of the "base" glyphs that determines the way such "composite" glyphs will be rendered (e.g. a single black shape, or with cuts and holes).
The text was updated successfully, but these errors were encountered: