pouët.net

Go to bottom

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 !
added on the 2004-06-06 17:50:24 by linkt linkt
For example the motion blur in Max Payne 2 is done very well...but how it is done ?
added on the 2004-06-06 17:55:11 by linkt linkt
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 ;)
added on the 2004-06-06 19:12:15 by psenough psenough
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...
added on the 2004-06-06 19:29:48 by kusma kusma
ask fr
added on the 2004-06-06 19:34:33 by apricot apricot
http://www.scene.org/file.php?file=/parties/2003/assembly03/seminars/20-dierk_ohlerich-a_history_of_farbrausch_tools_xvid.avi&fileinfo
added on the 2004-06-06 19:44:16 by mjz mjz
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
added on the 2004-06-06 20:00:58 by kb_ kb_
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'.
added on the 2004-06-06 20:24:56 by superplek superplek
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.
added on the 2004-06-06 20:51:23 by NeARAZ NeARAZ
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).
added on the 2004-06-06 21:07:24 by ryg ryg
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 :))
added on the 2004-06-06 22:32:24 by NeARAZ NeARAZ
*ryg, not rug :)
added on the 2004-06-06 22:32:56 by NeARAZ NeARAZ
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?
added on the 2004-06-06 22:54:44 by 216 216
NeARAY: don't rub ryg the wrong way.
/me go to bed
added on the 2004-06-06 23:43:38 by p01 p01
Personally I wouldn't rub ryg at all -- I don't find him attractive.
<insert random less-than-perfect ryg pic from slengpung here>
added on the 2004-06-07 01:09:14 by Gargaj Gargaj
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
added on the 2004-06-07 02:01:33 by texel texel
zoomblur != radialblur
added on the 2004-06-07 02:18:53 by kusma kusma
nanook: work around this problem by using a second texture for accumulation.
added on the 2004-06-07 04:46:22 by ttl ttl
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.
added on the 2004-06-07 06:09:08 by mjz mjz

login

Go to top