The 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 pr

The 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.