Motion blur is a contentious subject in games because it's often done very poorly. The biggest three crimes are blurring an object too far, blurring things tha

Motion blur is a contentious subject in games because it's often done very poorly. The biggest three crimes are blurring an object too far, blurring things that shouldn't be blurred, and blurring an entire scene (which I guess just results in #2, so maybe there's really only two crimes). The most important thing is that motion blur should be subtle. Properly-done motion blur doesn't make a game look blurry, it makes it look more real and smooth. If an object is moving 50 pixels between frames, then the blur should not be more than 50 pixels wide. Really, it should likely be only 25 pixels to make the blur more subtle. But for some reason, racing games love to apply a full radial blur to an entire scene while going fast, and to me it just ruins it. Likewise, an object that is not moving relative to the camera should have no motion blur at all. This is where so many games get it wrong. As you rotate, they blur the scene using post-processing. In a completely static scene, this makes sense and is a very computationally-efficient way to perform motion blur. But if you're rotating because you're tracking an object, the tracked object should not be blurred. If you're in a racing game and the car next to you is going the same speed as you, the other car should not be blurred. Really, the only guaranteed way to get correct motion blur is to render multiple entire frames in a row and then blend them, but you need a LOT of samples to make this look good, or else something like a vertical line looks like a series of vertical bands as it flies across the screen, rather than a smooth blur. The best is probably a hybrid approach. Render each object in the scene on its own and apply a post-process blur on a per-object basis based on which direction it is moving relative to the camera. Though Z-ordering could end up becoming a major challenge.