1
0
mirror of https://github.com/Pomax/BezierInfo-2.git synced 2025-08-18 22:41:49 +02:00

Fix typo. (#284)

This commit is contained in:
Steve Nicholson
2020-11-27 10:46:14 -08:00
committed by GitHub
parent 3bef22af06
commit 608680a16b

View File

@@ -83,7 +83,7 @@ findClosest(start, p, r, LUT):
return start + i
```
In words: given a `start` index, the circle center and radius, and our LUT, we check where (closest to out `start` index) we can find a local minimum for the difference between "the distance from the curve to the circle center", and the circle's radius. We track this by looking at three values (associated with the indices `index-2`, `index-1`, and `index`), and we know we've found a local minimum if the three values show that the middle value (`pd1`) is less than either value beside it. When we do, we can set our "best guess, relative to `start`" as `index-1`. Of course, since we're now checking values relative to some `start` value, we might not find another candidate value at all, in which case we return `start - 1`, so that a simple "is the result less than `start`?" lets us determine that there are no more intersections to find.
In words: given a `start` index, the circle center and radius, and our LUT, we check where (closest to our `start` index) we can find a local minimum for the difference between "the distance from the curve to the circle center", and the circle's radius. We track this by looking at three values (associated with the indices `index-2`, `index-1`, and `index`), and we know we've found a local minimum if the three values show that the middle value (`pd1`) is less than either value beside it. When we do, we can set our "best guess, relative to `start`" as `index-1`. Of course, since we're now checking values relative to some `start` value, we might not find another candidate value at all, in which case we return `start - 1`, so that a simple "is the result less than `start`?" lets us determine that there are no more intersections to find.
Finally, while not necessary for point projection, there is one more step we need to perform when we run the binary refinement function on our candidate LUT indices, because we've so far only been testing using distances "closest to the radius of the circle", and that's actually not good enough... we need distances that _are_ the radius of the circle. So, after running the refinement for each of these indices, we need to discard any final value that isn't the circle radius. And because we're working with floating point numbers, what this really means is that we need to discard any value that's a pixel or more "off". Or, if we want to get really fancy, "some small `epsilon` value".