Implement closest_point for Segment[23]d. #20130
Conversation
IQuick143
added
C-Feature
| let closest = segment.closest_point(*point); | ||
| assert!( | ||
| point.distance_squared(closest) <= point.distance_squared(segment.point1()), | ||
| "Closest point must always at least as close as either vertex." |
There was a problem hiding this comment.
I think this sentence is missing a "be"
| @@ -2349,15 +2349,15 @@ mod tests { | |||
| let closest = segment.closest_point(*point); | |||
| assert!( | |||
| point.distance_squared(closest) <= point.distance_squared(segment.point1()), | |||
| "Closest point must always at least as close as either vertex." | |||
| "Closest point must always at be least as close as either vertex." | |||
There was a problem hiding this comment.
hum, it's "must always be at least" x) sorry for pestering :p
There was a problem hiding this comment.
Brain not working today, oops.
There was a problem hiding this comment.
Looks good! Pretty much exactly the same implementation as what I have in Peck.
This uses a more intuitive and simple approach in terms of the naming and comments, whereas I (and Parry, Box2D, etc.) explicitly describe the barycentric coordinates and Voronoi regions (see the version I linked on Discord). Both are fine for this line segment case, but for the more complicated simplices like triangles and tetrahedra, IMO you really need to use Voronoi regions to make sense of things.
I'm kind of biased towards using barycentric coordinates and Voronoi regions for all simplices to have them be more consistent and kind of build on each other, but I'm fine with this for now :)
|
Also I expect these to be moved under a trait like |
IQuick143
added
S-Ready-For-Final-Review
| return self.vertices[0]; | ||
| } | ||
|
|
||
| let length_squared = segment_vector.length_squared(); |
There was a problem hiding this comment.
Wondering about precision here. Since the value is scaled by the segment length it's potentially quite large already, and squaring it could lead to precision issues. On the other hand normalizing first wastes cycles for the early out case. Thoughts?
There was a problem hiding this comment.
You really cannot get a better precision than this. Because the actual length is computed as the square root of length_squared (which is computed through the pythagorean theorem), in fact one of the reason I'm using the length squared here is to skip on the square root operation that would end up being redundant here.
Due to how f32 numbers work, they have roughly the same amount of precision (as in, how many digits are correct) regardless of scale. So the number just being large is not a problem, problems arise when one tries adding together large numbers and small numbers, because then the small number gets lost in the rounding error of the large number. Or a better example: When subtracting two large numbers, and the result is a small number: The small number is going to be largely influenced by rounding on the large ones.
However if the operations are only multiplication or division, or addition of numbers of similar magnitude, then this is not a concern. (Ofc other concerns such as f32 error accumulation apply.)
As an example: The t parameter at the end will always* have around 5 digits of precision, since it's computed as a quotient of two numbers which have a similar* error.
There's practically no additions in this algorithm, except:
Vec3::dot, Vec3::length_squared and the vector operations at the end.
As I've said Vec3::length_squared is really the best measurement of length we can obtain.
The vector operations at the end are fundamentally constrained by the precision of the input points, if your points have coordinates on the order of 1megaunit, then they will have an error on the order of units, so the output of this method will obviously have a similar error. If you scale the whole thing down, the error also scales down.
The potentially most problematic component is Vec3::dot, where the situation of "subtracting two very close large numbers" might occur, if you have a point 1Mu far away from your line segment, which is a bunch shorter, and the point is roughly orthogonal to the line segment, then projection_scaled, might have a surprisingly large error, compared to the magnitude of length_scaled.
But I consider the limitations of Vec3::dot when dealing with extremely long nearly orthogonal vectors to be beyond my scope.
Nonetheless, you do make a good point, I appreciate that people are thinking about the precision issues during review.
| ); | ||
|
|
||
| let segments = [ | ||
| Segment2d::new(Vec2::new(0.0, 0.0), Vec2::new(0.0, 0.0)), |
There was a problem hiding this comment.
Add one very long segment?
Objective
Solution
Testing