34 ms·
You can see what's wrong with that approach by considering the difference between traveling at constant speed along the arc of a circle versus traveling at cons
by gugagore 5y ago
You can see what's wrong with that approach by considering the difference between traveling at constant speed along the arc of a circle versus traveling at constant speed along a chord, and projecting the point (out from the center) onto the arc.
It works great if the chord is far away from the center (and also the angle is less than a half turn). If the chord goes through the center, it doesn't work at all.
- Chabsff 5y ago10-12 years ago, the consensus used to be that this singularity simply does not show up in the wild in the vast majority of scenarios, and the performance hit of using `slerp()` is just not worth it unless truly needed. It was essentially the same reasoning as for using `-ffast-math`. Yeah it's not "correct", but users can't tell the difference and it has a measurable performance benefit. To be clear, I'm not questioning using slerp() at all, it definitely has a role to play. I'm just wondering about using it by default as implied by the post.
- gugagore 5y agoYeah, I understand. I just wanted to show that one can understand the exact nature of the approximation in 2D geometry. I think it's useful to think of it as a separate category of "wrong" than -ffast-math, which is "wrong" because two expressions that are mathematically equivalent over real numbers, like a + (b + c) and (a + b) + c, are not equivalent over floating-point numbers. Using lerp in place of slerp is like using x in place of sin(x). (The small-angle approximation) They're not equivalent over the real numbers.
- Chabsff 5y agoMy apologies. I thought you were providing an explanation as to why slerp() is preferred in general. The circle example is a really good way to frame the distinction.