
Bloom by SantaClaws.

r_bloom 0 turns bloom off.
r_bloom 1 turns on a faster bloom, but it doesn't bloom nearly as well.
r_bloom 2 turns on the good bloom, that you see in the screenshots.

Note(by Dante_UK): I've set r_bloom 0 by default.

Also note that, as this is doing a lot of operations per pixel, you're definitely going to notice a drop in performance at higher resolutions. In 640x480 (my resolution, because my computer sucks), the performance drop is negligible.

There is a lot of work left to do on it, but the future changes are going to start drastically changing the way some of the stuff in Doom 3 works, and will require custom content to make any sense. So, I figured I would release it at this stage so people could mess around with it while it's still compatible with the normal game content. In the end I'd want to have something that does a bit better emulation of the >1.0 range of floating point buffers, and is able to isolate the lighting reflection from the bright unlit diffuse surfaces (like a whiteboard).

Because Doom 3 wasn't designed with this in mind, there are some places where it blooms a bit too much (such as the forehead of Swan when talking to Bertruger at the starting of the game).

With r_bloom 2 it is doing a LOT of extra work:

1) Save a copy of the current render before the screen has been bloomed.
2) Per fragment: Isolate areas to be bloomed.
3) Capture current render to texture for next pass.
4) Per fragment: gaussian blur horizontally, 17 samples (current fragment. and 8 fragments on the left and right).
5) Capture current render to texture for next pass.
6) Blur vertically, 17 samples and combine with pre-bloom texture.

Just counting texture sampling, that's an additional 36 texture reads per pixel per frame.

r_blur 1 shouldn't drop your FPS so much, but it doesn't blur nearly well because it's only doing a 1 pass blur and combine, sampling only 8 fragments in a diamondish shape around each fragment.

Ideally the material could adjust the amount of blur depending on a user setting, without having to resort to the r_blur 1 method, but I haven't implemented anything like that yet.

If you know VFP syntax, you can easily modify the amount of sampling it's doing per blur pass in the files bloomBlurX.vfp and bloomBlurY.vfp, but make sure to adjust the multipliers accordingly or the blur won't be averaged out correctly.