Downsampling images before a blur seems to be a pretty standard technique to get more perceived bang (blur) for your buck. If you don't downsample the image too far, the blur adequately covers any artifacts the downsampling (and re-scaling) would have. The result is, an N radius blur can be stretched a lot farther, because the downsampling (and re-scaling) itself adds an blur of its own.
This performance optimization doesn't really work for variable-width blurs (like depth of field) on 3d scenes though, because some parts of your image need to be crisp, while others blurred. Downsampling the entire image would lose resolution on the crisp parts.
3d depth of field blurs are actually pretty interesting though. They're variable width, which is just another way of saying that each pixel on the final image might be blurrier or less blurry than another pixel. Implementing this kind of variable blurring is a tough task, and typically done by scaling up or scaling down a disk of random sampling coordinates for each pixel. When the disk of coordinates is large, the sampling coordinates sample further from the pixel its centered on, so the resulting pixel has a bigger blur. When the sampling disk is small, the surrounding coordinates are closer to the center pixel, creating a smaller blur. The size of this sampling disk is controlled by the depth of the pixel from the near and far focus planes of the virtual camera.
> This performance optimization doesn't really work for variable-width blurs...
An alternative would be to use Summed-area tables [1] where each texel contains the sum of all texels that are above and to the left of the current texel. This allows variable-width blurs to be computed in constant time, using only four texture samples (!).
And the concept of a variable-width blur is an approximation to a related concept in photography/optics called the "circle of confusion." [2] The circle of confusion, combined with bokeh sprites, are usually what AAA games are doing for depth of field [3].
I love this stuff. I haven't had a chance to implement a summed area table yet for anything, but I did do variance shadow maps very recently (did you mean to cite that?). I did read about them though, and one drawback that I remember was that you might have a precision overflow in the bottom/top corner where the summations are the greatest?
The GPU Gems article talks about summed area tables in the context of variance shadow maps, specifically percentage closer soft shadows variance shadow maps where variable-width blurs are used extensively. Didn't really mean to cite the stuff about VSMs (sorry), more so the SAT stuff toward the latter half of the article as it would apply to DoF.
I believe the precision/overflow issues can be mitigated using modern GPU hardware (the authors mention this in section 8.5.2 of the article.) Now-a-days it is pretty much standard to have floating-point render targets (especially with deferred rendering and light-pre pass renderers) so 16/32 bits per component should be adequate especially if you apply the tricks the authors present in the article. Not to mention that now we have DirectCompute/OpenCL/CUDA.
Though I don't really see people talking about SATs that much (I myself have never implemented them.) Maybe there is an underlying reason why people don't? Bandwidth maybe? I would imagine it would be pretty taxing on the system to recompute the SAT every frame.
In 3D games with significant view distance, they often use low resolution copy's for displaying distant objects. These low resolution copy's are progressively replaced with ever more complex versions as you approach. I suspect you could mix in some blur to get a smoother transition and enable even lower resolution copy's while avoiding the 'pop' that occurs when you suddenly get the high rez version of an object.
This performance optimization doesn't really work for variable-width blurs (like depth of field) on 3d scenes though, because some parts of your image need to be crisp, while others blurred. Downsampling the entire image would lose resolution on the crisp parts.
3d depth of field blurs are actually pretty interesting though. They're variable width, which is just another way of saying that each pixel on the final image might be blurrier or less blurry than another pixel. Implementing this kind of variable blurring is a tough task, and typically done by scaling up or scaling down a disk of random sampling coordinates for each pixel. When the disk of coordinates is large, the sampling coordinates sample further from the pixel its centered on, so the resulting pixel has a bigger blur. When the sampling disk is small, the surrounding coordinates are closer to the center pixel, creating a smaller blur. The size of this sampling disk is controlled by the depth of the pixel from the near and far focus planes of the virtual camera.
I've glossed over a lot (like the artifacts that can result from 3d DoF), but Nvidia's GPU gems has a great article on the subject http://http.developer.nvidia.com/GPUGems3/gpugems3_ch28.html