Gaussian blurr a Direct3D Surface.
Author
Does anyone know how to perform a gaussian blurr on a Direct3D surface? Any tutorials out ther?
Thanks
One way to do it would be with a pixel shader. Render a quad the exact size of the image you want to apply the gausian blur to. Then in your pixel shader, you can mess with the texture coordinates to get the texture samples you need and do the maths for the blur. The result of these maths is what your pixel shader outputs.
neneboricua
neneboricua
Author
If at all possible I would like to avoid the use of pixel shaders. Thanks for the idea, but does anyone know a way to do it in DirectX 8 without pixel shaders?
Lock the texture's primary surface and do a Guassian blur on the pixel data just like you would on any other pixel data stored directly in memory? If you need an algorithm for the blur, I recently implemented this one, which seems to work quite well, and quite quickly. Took some effort to translate the PDF into working code, though. If you were merely unaware of locking textures in DirectX, look up IDirect3DTexture8::LockRect(). That'll give you a pointer to the pixels, and the number of bytes in each row. With a bit of type-casting, you can treat the memory like an array. An array of D3DCOLOR, if you happen to use D3DFMT_A8R8G8B8, which makes it even nicer.
Author
Excellent! This is exactly what I was looking for. I was aware of the Locking surface, I just needed a gaussian blurr algorithm. One last question. What I'm going for is a glowing effect. what I'm thinking right now is to render the object I want to glow to a second surface. Then right before I render my back buffer to the screen, I was thinking I could add the color values of my "Glow Surface" to my back buffer surface. Does this make sense, or is there a better way. So in other words here's my plan:
1. Render all objects to back buffer.
2. Re-Render Glowing objects to a second surface.
3. Apply a gaussian blurr to the second surface.
4. Add the color values of each pixel in the second surface to the back buffer's surface.
5. Render scene.
Please let me know if this sounds reasonable or not.
1. Render all objects to back buffer.
2. Re-Render Glowing objects to a second surface.
3. Apply a gaussian blurr to the second surface.
4. Add the color values of each pixel in the second surface to the back buffer's surface.
5. Render scene.
Please let me know if this sounds reasonable or not.
It does sound somewhat reasonable to me; sounds about the same as other methods I've read about (though I haven't actually implemented any of them). A good article to check out would be Gamasutra's Real-Time Glow. They use pixel shaders, I believe, and it would probably help keep the performance up, but I think it should be sufficiently doable by using a dynamic texture as well.
I haven't tried this, but the theory behind it is very simple. If you render everything you wanted blurred to a texture, then render 9 quads (for a 3x3 blur) with that texture on it... using alpha blending. Thus, you can do it without Pixel shaders.
Thus for a...
1 1 1
1 1 1
1 1 1
...blur:
1) Render screen-quad with x:-1 and y:-1 pixel offset, 100% opacity.
2) Render screen quad with y:-1 pixel offset, 50% opacity.
3) Render screen quad with x:+1 and y:-1 pixel offset, 33% opacity.
4) Render screen quad with x:-1 pixel offset, 25% opacity.
5 to 9) Render screen quad n with x: and y: pixel offset, 1/n opacity.
If you want a different blur-matrix, you need to calculate the opacities different.
I guess it might be possible to build up all the 9 quads (or 25 quads for 5x5) in a single vertex buffer and store the opacity in the vertex-color. But I'm not sure if the draw order is guaranteed (since drawing them ordered is a must).
Thus for a...
1 1 1
1 1 1
1 1 1
...blur:
1) Render screen-quad with x:-1 and y:-1 pixel offset, 100% opacity.
2) Render screen quad with y:-1 pixel offset, 50% opacity.
3) Render screen quad with x:+1 and y:-1 pixel offset, 33% opacity.
4) Render screen quad with x:-1 pixel offset, 25% opacity.
5 to 9) Render screen quad n with x: and y: pixel offset, 1/n opacity.
If you want a different blur-matrix, you need to calculate the opacities different.
I guess it might be possible to build up all the 9 quads (or 25 quads for 5x5) in a single vertex buffer and store the opacity in the vertex-color. But I'm not sure if the draw order is guaranteed (since drawing them ordered is a must).
Author
Quote:Original post by Anonymous Poster
You should NOT lock the texture and modify it on the CPU. Performance will be horrible.
Are there any alternative suggestions other than using pixel shaders? Is this still a problem even if I only lock the texture once a cycle? I would prefer to stay away from pixel shaders because I have heard that many cards do not support them. Is this accurate, or am I being paranoid?
Thanks
Quote:Original post by Battagline
Are there any alternative suggestions other than using pixel shaders?
Take a look at emdin's post.
Quote:Original post by Battagline
Is this still a problem even if I only lock the texture once a cycle?
I believe that it will slow down things a lot, though I haven't tried it before...
Quote:Original post by Battagline
I would prefer to stay away from pixel shaders because I have heard that many cards do not support them. Is this accurate, or am I being paranoid?
I believe you're being paranoid :P
Almost all graphics card supports simple fragment/pixel and vertex shaders nowadays... but if you still want to stay away from shaders, as I said before, take a look at emdin's post.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
