Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Afterglow And Poll

Sign in to follow this  



I have had a post-processing filter in my engine for a long time, but it wasn't very blurry, even though I was using a 5x5 gaussian kernel. Instead, it acted like more of a saturation boost than a glow or blur.

On Sunday I decided to track down the issue once and for all. Turns out I was only doing it half right. A while ago I experimented with the StretchRect() method, where you just take, say, a 1024x768 screen and StrectchRect() it down to a 256x256 texture, then stretch it back over the screen. I found this method wanting, due to the large amount of temporal aliasing. This sort of blinking on and off effect was very apparent in a few demos I'd seen, and even in an earlier build of Guild Wars. Not sure if they've fixed it since.

One way to reduce this while still using StretchRect(), which is nice because it's easy, would be to do 4 offset StretchRects, then blend them all together. This large decimation method definitely thrashes the texture cache, because you are minifying the texture so much that you are pulling in a lot of texels into the cache that are never used. In this example, only 1/2 of the texels horizontally and 2/3 of the texels vertically are re-used, taking bilinear filtering into account.

Instead, I was taking my screen rez, stretch recting offscreen to a front-buffer sized ( 1024x768 ) tetxure ( to work nicely with AA ), and then sampling this front-buffer-sized texture into a 1/5 size texture in width, then filtering the front buffer again, this time to a 1/5 height texture.

That 2nd filter step was the bug. Instead, I fixed it to to go from 1 x 1 -> 1/5 x 1 -> 1/5 x 1/5

Then I take 4 offset samples of the small 1/5 x 1/5 texture, threshold it, then add it back over the scene. This creates a nice glow effect without very much temporal aliasing at all.

I also cleaned up the code a bit, and added more text-tweakable parameters, like the blur kernel width. Right now I support off, 3x3, 5x5, 7x7 and 9x9. I settled on the 5x5, as it gives a nice effect with very minimal strobing.

Here are two shots of the blur without thresholding. It also shows the two camera zoom levels available - one for immersion, the other for tactics :

I'd like to do a poll of those reading this journal. Please respond in the comment section.

Do you prefer the close camera, far camera, or the option to have both?
Sign in to follow this  


Recommended Comments

In general I prefer the nearer camera. Whether I'd ever want to use the far view depends on your game design.

Share this comment

Link to comment
Both. The near camera is good for close work and depending on the game the far camera seems like it'd be useful for navigation and/or 'getting the whole picture'

Share this comment

Link to comment
Both. I'll only ever use far but supporting both would be nice anyway. Maybe have a smooth zoom in/out control.

Share this comment

Link to comment
Both, for same reasons as given by evolutional, although the close camera can also be used for long range navigation down a hallway.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!