pouët.net

blur methods

category: general [glöplog]
kusma, true, but it looks similar... in the most of the cases, enough similar to lie the eye. And it is so fast. I didn't known it was called zoomblur. So, do you know if it could be done by hardware? I think it looks better (smoother) than the render to texture and then 2^n transparent layers of that, and I suppose that zoomblur should be faster than rendering n transparent layers (if it could be done by hard). I know nothing about hardware rendering. I loved the blur in the Bakkslide 7, that 2 passes, with accumulative blur. It looks not enough "gaussian", but it rocks. I coded some "gaussian" similar blur (software blur) in 4 pass, the curve is not gaussian, but it looks a bit better than the bakkslide 7. In the accumulation, I did not a color=c(n)+acumulation-c(n-k) (where k is the level in pixels of blur), but also a color=c(n)*k+acumulation*(1-k), where k is a real between 0 and 1. This in four pass, left to right, right to left, up to down, down to up, gives a beatiful blur, doesn't give any border and the blur level is real, not int, so lots of blur possibilities. But it is slow ... I always think in how Photoshop's gaussian blur is that fast... try it with a big enough image, do a big radius gaussian blur, take a look of the time it takes, then think in the clock times... it is impressively fast. I have no idea of how they did it... any ideas?
added on the 2004-06-07 06:11:15 by texel texel
You're not talking about fullscreen radial blur are you.
Have a look at mine.
http://www3.sympatico.ca/martvx/projects.html
Well in fact I can apply my algo to a texture.
It pretty slow.

This is the one I prefer next to motion blur.
added on the 2004-06-07 06:18:43 by duffman duffman
nanok: it's framerate-dependant, and it does NOT look similar with the exception of static or really really slow paced scenes. wich looks ugly. radialblur looks good on scenes with high pace, not ambient-shit. and yes it can be done with hardware. however, i don't really see the big issue here. both radialblur and "normal" box-blur can be performed quite fast in both hardware and software. gaussian blur is a different case, it works quite well in hardware, but i have yet to see a fast enough implentation in software. however, who cares anyway? just make the stuff look cool, damnit ;)
added on the 2004-06-07 10:24:33 by kusma kusma
thx for the serious answers :)

I watched the xvid about chaos describing some blur techniques. Using two textures for "crashzoom (radial blur"...which size would you recommend for best quality in high resolutions ? 512x512 or 1024x1024 ?

Isn't 512x512 already to small for demo resolutions
higher than 1024x768 ? Or doesn't such small textures (zoomed and blended) over a scene rendered in 1280x1024 create results of poor quality ?
added on the 2004-06-07 20:22:04 by linkt linkt
It is relatively easy to do an adequate-speed gaussian blur in software: The idea is to approximate the gaussian kernel by an approximation that leads itself to an efficient implementation. It turns out that uniform b-splines provide a good-quality approximation that both has nice analytical properties (like smooth second-order derivatives everywhere) and some features that make implementation easier (notably, the kernel will always have finite support, so no capping values as they become to low necessary).

A nice paper on the type of function you'll want to use is http://graphics.cs.ucdavis.edu/CAGDNotes/Uniform-B-Splines-as-a-Convolution.pdf
- the nice bit being that the function is created via repeated convolution of the haar function (basically our box filter kernel) with itself.

Now, convolution is associative. The typical way to implement a blur is by direct convolution with the kernel, in our case something like

(image conv (box conv (box conv box)))

i.e. you first complete the "final" kernel and convolve the image with that. But you get just the same result by doing

(((image conv box) conv box) conv box)

that is, just blurring the image with a box filter (which has very efficient software implementations) three times.
added on the 2004-06-07 21:09:23 by ryg ryg
Hi kusma. I'm not talking about a framerate dependant effect. I have no idea of how to call it, but it is one pass, and it looks ok. You can see it in the minimal54 of minimalanimal.
added on the 2004-06-08 00:40:51 by texel texel
feedback-effects are ALLWAYS framerate dependant. you can scale the animation to hide some of the artifacts, but they are allways there in some way.
added on the 2004-06-08 01:02:56 by kusma kusma
kusma, that ain't a feedback effect, it's a very simple IIR lowpass filter applied to the picture.
added on the 2004-06-08 08:54:08 by ryg ryg
Oh will you all shut up, blurring is so 1997. Try to do something original instead, like slowly rotating abstract envmapped objects ;)
added on the 2004-06-08 09:43:33 by kurli kurli
ryg: 'I mean a "feedback".'
added on the 2004-06-08 10:59:19 by kusma kusma
...

seriously, if you neither read the postings correctly nor apparently have any idea talking about, why don't you just stfu?
added on the 2004-06-08 11:12:39 by ryg ryg
maybe ryg should come to scene event too so you two can fight it out like real men.
added on the 2004-06-08 11:21:29 by skrebbel skrebbel
i suggest sota.. BB Image
added on the 2004-06-08 13:37:13 by lodda lodda
BB Image

MORE LIKE BLUR-SOTA

LOL I MEAN DO YOU GET IT??????
added on the 2004-06-08 15:33:34 by lylh lylh
@kusma

It's neither "ALLWAYS" nor "allways"... it's just always ;)
added on the 2004-06-08 15:43:16 by linkt linkt
linkt: OH MY GOD, A GRAMMAR ERROR ON INTERNETT!!!1 Now fuck off, please.
added on the 2004-06-08 16:04:13 by kusma kusma
Kusma: It was a spelling error - not a grammatical one ;-)
added on the 2004-06-08 16:15:25 by samwise samwise
on internet always may be written in all ways, so even like allways
added on the 2004-06-08 16:33:43 by ttl ttl
samwise: DAMN YOU!! ;)
added on the 2004-06-08 18:04:15 by kusma kusma
I think it`s best i keep my mouth shut.....
added on the 2004-06-08 18:17:11 by Zplex Zplex

login