3 ms·
as for why lerp+normalize isn't enough: it all depends on the distance between things being blended, no? With far away end points, the apparent speed of the ro
by an1sotropy 5y ago
as for why lerp+normalize isn't enough: it all depends on the distance between things being blended, no? With far away end points, the apparent speed of the rotation would be fast, slow, fast, at the beginning, middle, end, which could be a bummer.
- Chabsff 5y agoThe two aspects that slerp() addresses over lerp() + normalize() are 1) it can deal with pole-to-pole interpolation 2) It always takes the shortest path. In practice, the former is often provably never going to happen, and the later doesn't actually matter from a qualitative standpoint: Quaternion interpolation will always look a bit weird over large angles, especially if there's a roll component to one of the orientations. As far as having a constant interpolation speed: again, this is rarely perceptible, and truly linear transitions from one orientation to another looks janky so some amount of filtering happens anyways (an ease-in-ease-out for example). But yeah, for very large interpolations, it can create a slight authoring/runtime skew. My rule of thumb used to be: use slerp() when the orientations can be at least 120 degrees apart, or when lerp() yields weird results. However, it's really rare to be interpolating over such a large orientation change, you almost always have a few keyframes or dead-reckoning syncs in between. Again: This might be an outdated perspective though.