Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clockwise path orientation is inverted when doing union #12

Open
anthrotype opened this issue Oct 27, 2017 · 3 comments
Open

clockwise path orientation is inverted when doing union #12

anthrotype opened this issue Oct 27, 2017 · 3 comments

Comments

@anthrotype
Copy link
Member

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.

import pyclipper

pc = pyclipper.Pyclipper()
# polygon has clockwise orientation
pc.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 here
print(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).

@anthrotype
Copy link
Member Author

/cc @typemytype

@jamiebull1
Copy link
Contributor

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.

@gbburkhardt
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants