One of the first game to use Bloom/Glow over the image was "TRON 2.0"
There's a sample and whitepaper that covers the technique there :

Nvidia SDK

Also look at the Gamasutra article by Greg James :
Real time Glow

LeGreg

Quote:Original post by unexist
1. Render the 3d portion of the scene to a texture the size of the back buffer.
2. Using the texture you just rendered to, for each pixel, multiply the rgb value of the color by the alpha value and put the result into a secondary texture.
3. Resize the texture with the alpha*rgb color data to 1/4 of the original size.
4. Perform horizontal gaussian distribution on the pixels that have color.
5. Perform vertical gaussian distribution on the pixels that have color.
6. Resize the texture back up to its original size.
7. Blend the original texture with the resized blurred texture you just created.
8. Copy the blended texture into the backbuffer and present.

This is all generally correct, and is common way of implementing glow/bloom. In fact, it's exactly the way its implemented in the Nvidia paper that LeGreg mentioned. But just to be clear, it's certainly not the only way to do things. For instance, it's also very common not store a glow value in the alpha channel and instead perform a threshold on the original texture. A shader to perform this is very simple:

float g_fThreshold = 0.65f;float4 PS(in float2 vTexCoord : TEXCOORD0) : COLOR0{    float4 vColor = tex2D(texSampler, vTexCoord) - g_fThreshold;    return max(g_fThreshold, 0);}

So what happens when you do this, is that bright areas of the image are bloomed "automatically", you don't have to output a glow value to the alpha channel when you're rendering all the 3D geometry. Of course this will give you different results, so which is better depends on what you want out of your bloom and how your rendering is laid out...if you're using the alpha channel for something else (like alpha-blending), then a threshold might be a better idea.

Quote:Original post by unexist
How do I write into an secondary texture from the pixel shader when doing the alpha*rgb operation? Is this as simple as calling device->SetRenderTarget(0, secondTexture) and then rendering the first texture from the sprite interface or is there a way to do it directly from the shader if I pass the second texture to it as a parameter?

Yes, you just call SetRenderTarget with index 0 and then render as normal. After you do that anything you output using the COLOR0 semantic will be written to that surface.

a) the surface has to be either be from a texture created in D3DPOOL_DEFAULT with the D3DUSAGE_RENDERTARGET flag, or created using IDirect3DDevice9::CreateRenderTarget
b) the surface has to be in a format the device can render to
c) the texture can't be bound to a texture sampler input (this won't actually produce an error, it'll cause undefined behavior. The debug runtime will produce a warning about it)

Quote:Original post by unexist
How do I resize the texture? The only way I know of is to create a texture of the appropriate size and then use the device->StrechRect() function. Can I do this in the shader as a pass by averaging each 4x4 block of texels of the larger texture and writing the result into a smaller texture? If so, once again, how do I write into another texture from the shader?

You can use StretchRect to resize a texture...the catch is that with linear filtering you'll lose data if you go resize to a size smaller than 1/2 the original texture. Two passes would work fine, or if you want to do it one pass then averaging a 4x4 block will do the trick. Doing the filtering manually in the shader also allows you to work with formats that can't be filtered by the GPU, for instance ATI X-series and X1000-series can't filter fp16 and fp32 formats.


For this topic, I very much recommend checking out the PostProcess sample in the SDK. It not only can demonstrate bloom, but also shows you how to handle general post-processing tasks: setting up a full screen quad, chaining together effects, ping-ponging between textures. Definitely worth spending some time with. [smile]

You can't pass a surface as input to a shader, you need to pass a texture. All textures have at least 1 surface, but not all surfaces belong to a texture. In particular the backbuffer is a surface, but one that doesn't belong to a texture. Therefore you can't directly read from it in a shader. However there are two simple, easy alternatives:

-Create a texture in the D3DPOOL_DEFAULT pool and then use StretchRect to copy data from the backbuffer to this texture
-Create a texture with D3DUSAGE_RENDERTARGET and render your 3D scene to this texture, instead of the backbuffer.

When you're doing all these downsampling and blurring passes, you have to render something. If you just call Begin and End on your effect, nothing will happen. You need to draw some geometry so that pixels are rendered to the current render target. The reason I mention a full-screen quad is because you want to make sure you render to every single texel of the render target, and the easiest/cheapest way to do that is just use two triangles that cover the whole screen.

If for now you don't want to mess around with handling the quad yourself, you can use ID3DXSprite. Just make sure when you call ID3DXSprite::Begin you pass the D3DXSPRITE_DONOTMODIFY_RENDERSTATE flag. Also make sure the Vertex Shader in your effect is set to NULL. Then you can just set the current texture you're sampling from, and draw a sprite that's the same size as the current render target.