blur methods
category: general [glöplog]
Which is your favorite blur method ? And do you know any OpenGL tutorials describing how to create good looking blur (motion blur, radial blur, etc...) ?
I already found some with google but they are all very simple (render scene to texture, blend, bla...) and the result isn't really looking good. Also the nehe radial blur isn't really good I think...
Any suggestions or links ? :)
Thx !
I already found some with google but they are all very simple (render scene to texture, blend, bla...) and the result isn't really looking good. Also the nehe radial blur isn't really good I think...
Any suggestions or links ? :)
Thx !
For example the motion blur in Max Payne 2 is done very well...but how it is done ?
haven't we been over this a million times allready ?
Take off your glasses. That oughta do the trick.
i like noise blur the bestest ;)
normal blur is usually solved with separable filterkernels and render-to-texture.
radial blur is best done the inopia-way ;)
render two layers to a texture, and then use that texture to render two more layers to another texture. then you do this over and over again. after 8 iterations, you have a texture with 256 layers...
radial blur is best done the inopia-way ;)
render two layers to a texture, and then use that texture to render two more layers to another texture. then you do this over and over again. after 8 iterations, you have a texture with 256 layers...
ask fr
http://www.scene.org/file.php?file=/parties/2003/assembly03/seminars/20-dierk_ohlerich-a_history_of_farbrausch_tools_xvid.avi&fileinfo
ps.1.1
tex t0
tex t1
tex t2
tex t3
add_d2 r0,t0,t1
add_d2 r1,t2,t3
add_d2 r0,r0,r1
tex t0
tex t1
tex t2
tex t3
add_d2 r0,t0,t1
add_d2 r1,t2,t3
add_d2 r0,r0,r1
Quote:
radial blur is best done the inopia-way ;)
Though you must have noticed the horrible artifacts this gives in the way it implies 'volume'.
Quote:
ps.1.1
tex t0
tex t1
tex t2
tex t3
add_d2 r0,t0,t1
add_d2 r1,t2,t3
add_d2 r0,r0,r1
really really synthetic! impressing! thumbs up for kb! xD
Or use approximation to real Gaussian as presented by M.Kawase in GDC2003. Basically just what kb writes, but repeat several times with increasing texel offsets (0.5, 1.5, 2.5 etc.). It doesn't produce real Gaussian, but it's pretty good and fast.
nearaz: we've used that technique for years (first used in fr-minus-04, coded half a year before :) and already documented it multiple times (i.e. on flipcode).
Mjz, thank you for that link, it was very informative, and I feel like that by watching that movie, I've kinda opened my mind for new ideas about how to make programs.
rug: Yes I know. But Kawase has a really nice presentation of this and some other postprocessing effects, with diagrams and such. I didn't say he invented this (hey, everything's already invented! afterall, computer graphics is just a bunch of dot products combined in funky ways :))
*ryg, not rug :)
ah, what you need is called convolution. just build a filter kernel that represents the weights of nearby pixels. then you need to go through the following:
the first thing is that a cyclic convolution can be turned into negacyclic and cyclic parts of half the size by simply calculating sums and differences of the first and second halves of a signal. this is just a couple of render-to-texture polygons. quick way to halve the problem.
neat huh? but wait - there's more. a negacyclic convolution of real numbers is also a negacyclic convolution of complex numbers where the imaginary parts simply follow real ones. this is a no-op so what's the use? to do a trick. now, when you're working with complex numbers you have you turn the negacyclic convolution into cyclic by multiplying the numbers with e^(x*j*pi/signal_length). this is just a couple of polygon fills as well. no big deal. then just go on and on till you have the whole stuff consisting of 1x1 pixels to be convolved with another. at this point you can simply multiply them and do the whole shit backwards.
tada. this must be insanely fast since it's essentially linear, right?
the first thing is that a cyclic convolution can be turned into negacyclic and cyclic parts of half the size by simply calculating sums and differences of the first and second halves of a signal. this is just a couple of render-to-texture polygons. quick way to halve the problem.
neat huh? but wait - there's more. a negacyclic convolution of real numbers is also a negacyclic convolution of complex numbers where the imaginary parts simply follow real ones. this is a no-op so what's the use? to do a trick. now, when you're working with complex numbers you have you turn the negacyclic convolution into cyclic by multiplying the numbers with e^(x*j*pi/signal_length). this is just a couple of polygon fills as well. no big deal. then just go on and on till you have the whole stuff consisting of 1x1 pixels to be convolved with another. at this point you can simply multiply them and do the whole shit backwards.
tada. this must be insanely fast since it's essentially linear, right?
NeARAY: don't rub ryg the wrong way.
/me go to bed
/me go to bed
Personally I wouldn't rub ryg at all -- I don't find him attractive.
<insert random less-than-perfect ryg pic from slengpung here>
does it is possible to render to texture in a texture you are using? I mean a "feedback". With that, there are some interesant radial blur effects, that I use to do with soft rendering
zoomblur != radialblur
nanook: work around this problem by using a second texture for accumulation.
Actually, you can use the same texture as render target and render source. It even creates relatively few artifacts in my case. However, I am not sure if this works the same way on all hardware. And I am quite surprised it works at all... Perhaps it is useful in special cases.
Using a second texture creates much more predictable results, and is not slower, it just requires more VRAM, so you should do that. I recommend you to watch the farb-rausch video I linked. Among many other thing, they also explain an efficient way to do blur.
Using a second texture creates much more predictable results, and is not slower, it just requires more VRAM, so you should do that. I recommend you to watch the farb-rausch video I linked. Among many other thing, they also explain an efficient way to do blur.