Fix: 2D tri/quad vs point intersection tests edge cases #117786

Merged
Aras Pranckevicius merged 1 commits from aras_p/blender:math_isect_point_fix into main 2024-02-03 19:03:29 +01:00

1 Commits

Author SHA1 Message Date
Aras Pranckevicius 93886337e8 Fix: 2D tri/quad vs point intersection tests edge cases
buildbot/vexp-code-patch-lint Build done. Details
buildbot/vexp-code-patch-linux-x86_64 Build done. Details
buildbot/vexp-code-patch-darwin-x86_64 Build done. Details
buildbot/vexp-code-patch-windows-amd64 Build done. Details
buildbot/vexp-code-patch-darwin-arm64 Build done. Details
buildbot/vexp-code-patch-coordinator Build done. Details
isect_point_tri_v2 and isect_point_quad_v2 are handling tris/quads
in either clockwise or counter-clockwise vertex orderings. However,
for clockwise order it was considering points that lie on the edges
or vertices as "inside", whereas for counter-clockwise it was treating
them as "outside".

Visibly affected place is VSE: it has an optimization that checks
whether a fully opaque strip image fully covers the rendered area.
When the strip was scaled up to *exactly* cover the rendered area,
the check was failing since isect_point_quad_v2 was saying that a
point is outside the rect.

As far as I can tell, the functions have been "slightly wrong" in
this way for at least 15 years; harder to see through earlier
history in git.

Added a bunch of unit tests to cover this. Without the fix, "edge"
and "corner" cases against "cw" tri/quad were failing.

Performance (checked on clang15 on M1 Max):
- isect_point_tri_v2 is pretty much the same performance (assembly
  several instructions shorter),
- isect_point_quad_v2 is about three times *faster* (assembly 2x
  shorter), seemingly the compiler is able to use some SIMD now.
2024-02-03 18:49:04 +02:00