1

I am wondering how the even-odd algorithm works for identifying a point in a complex polygon.

What I know right now is that it will do the horizontal search from most left to the point and count the number of edges touched.

However, what happens if the edges touched is in an intersection of 2 edges? how does it count?

Example of polygons:

Examples of polygons

m69's been on strike for years
  • 11,835
  • 3
  • 34
  • 57
Shing Chi Ng
  • 31
  • 1

2 Answers2

4

The way I like to do it, which works for integer as well as floating-point coordinates, is:

  • for non-horizontal segments, each segment includes its bottom-most point but not its top-most point.

  • do not include the horizontal segments at all in the even-odd count.

This ensures that the even-odd count is correct for every point inside the polygon and every point outside, but it's not entirely consistent about points exactly on the boundary. If it matters to you, you may want to add a rule that any point that is actually on a segment is included in the polygon.

Matt Timmermans
  • 53,709
  • 3
  • 46
  • 87
0

there are more ways of dealing with this problem but the safest I know of is to

Change ray direction slightly

this is numerically safe but implementation is not as easy as it sounds. Either change entire ray and compute from the start or change somewhere before the hit in question.

change ray direction

You need to ensure that you do not form close loops for example by zig zag pattern (so you alternate between turning CW and CCW within some cone from the original direction).

In case where ray is exactly parallel to and also touching an edge of your polygon either ignore such edge or count it twice or change the ray direction again.

Changing ray direction is always safe as it avoids singularities and numerical instabilities.

btw. This inside polygon algorithm you are using is well known by name Hit test

Community
  • 1
  • 1
Spektre
  • 49,595
  • 11
  • 110
  • 380
  • The redirected ray might hit another vertex, this is not bulletproof. –  Oct 10 '18 at 07:52
  • @YvesDaoust Yes it might in such case you change direction again ... I taught that was obvious (from the ZIG ZAG pattern) I know that implementing this is much slower than other techniques like in the other answer but its the only safe way I know of. Even approach from the other answer is a numerical stability risc and does not work on floats under certain conditions. – Spektre Oct 10 '18 at 07:55
  • The approach described by @Matt Timmermans is provably safe and does not require to degrade the data. It can also be proven that with very simple requirements of the arithmetic (essentially monotonicity) there are no numerical issues (no point going wild). –  Oct 10 '18 at 07:58
  • @YvesDaoust On paper may be but in real life sometimes even `ulp` error can mess this up. Especially if scaling or any other transformation is present not just raw data. In such case sometimes the touching of vertex can be correctly detect in only one of the edges instead of both causing havoc. Those cases needs special handling and are not safe if there are other non touching vertexes nearby (very close edges to each like almost touching screws of a spiral and so on) but such polygons are not the usual ones that are used however I am dealing with them sometimes in my line of work, – Spektre Oct 10 '18 at 08:10
  • No, an `ulp` will not mess up. –  Oct 10 '18 at 08:12
  • @YvesDaoust also the other answer does not dealing with the touching tooth point and this does. – Spektre Oct 10 '18 at 08:12
  • I don't think you understood that solution. –  Oct 10 '18 at 08:17
  • @YvesDaoust most likely as I still not see how it could work with tooths touching rays. – Spektre Oct 10 '18 at 20:50