Memorable radial blur you've seen(not just demos)
category: general [glöplog]
radial blur is so nice.
http://www.youtube.com/watch?v=bf1pStwczVA&feature=related
only the beginning( first 10 seconds )
Haujobb - Discloned
http://www.youtube.com/watch?v=bf1pStwczVA&feature=related
only the beginning( first 10 seconds )
Haujobb - Discloned
The one in the World Food Program commercial with Sean Connery.. it looks like it's from a NeHe tutorial.
preacher that one scarred me for life
tbl did it with backlights!
http://www.youtube.com/watch?v=rDh9EAQyLEQ only decent one from demoscene ive seen.
This is like thin rays that look ugly, not my favorite.
Btw,. which technique is used to make the radial blur emit such huge rays? A late example I remember is Solaris-Kiss our Assembler demo. There, the radial blur is as I like it. But when I tried to do radial blur it didn't emit so huge rays, I mean the rays had some short length where they faded out. What am I doing wrong?
Btw,. which technique is used to make the radial blur emit such huge rays? A late example I remember is Solaris-Kiss our Assembler demo. There, the radial blur is as I like it. But when I tried to do radial blur it didn't emit so huge rays, I mean the rays had some short length where they faded out. What am I doing wrong?
I used the suggestion of Kusma here. Maybe I should just take more sample pixels on the radius to make stronger rays or something?
How do you do radial blur? My own near-radial blur method can be seen in some of my prods, for example in kilomegagigaterapetaexademo by minimalanimal (also in Jesus was a Pouet Glopper), it is not completely exact but it is in only one screen pass, so it is so fast.
I know some people use several zoom resized and mixed images, 2x, 4x, 8x... but it doesn't use to be very good looking... and it is also not exact... so, how do you do it?
I know some people use several zoom resized and mixed images, 2x, 4x, 8x... but it doesn't use to be very good looking... and it is also not exact... so, how do you do it?
I've just seen the forum by optimus... I do it the kusma way
*bilineal
rubicon 2 had some nice radialblur-like thingies
I always digged the rotational blur more than radial, as it wasn't likewise terribly overused back in the 90's. :)
one of the best (if not the best) radial blur examples is the one on the spinning ball from "the nonstop ibiza experience" by orange...
Also "viagra" and any other mewlers intro comes to my mind...
Also "viagra" and any other mewlers intro comes to my mind...
... what is fun with this effect, is that the hardware-accelerated way you code it has nothing in common with the software-rendered way, which you can manage to do in one pass.
friol actually the ball from nonstop ibiza experience suffered from the same problem as a shitload of radial/zoom blur effects in the 90's: not brightening the screen (or otherwise underlining the fact that) when "light beams" point straight at the camera, making the whole effect seem flat and without balls.
PORCH-MONKEY
it's actually quite similar. say T maps an image x to a slightly zoomed version (by a factor f) x'. So x=1x=(T^0)*x=original image, Tx=image zoomed by factor f, (T^2)x=T(Tx)=imaged zoomed then zoomed again=image zoomed by factor f^2 and so on. you want to blend a couple of those zoomed versions, so your final image would be
and you'd typically want n to be large so you don't see the individual copies. adding a lot of zoomed copies with scaled-down intensity is both slow and low-quality because of limited framebuffer precision (but still, i've seen people do it like that). what you do with hardware is assume that n=2^m (i'll use m=4 for the example, typically you want m>=6) and then use the fact that
Applying that to an image boils down to:
there's nothing holy about using 2-term groups; the main limit is the number of texture stages, really (when we first did this, there was only 2 of them). our later versions used groups of 4 (still good precision and ended up being a bit faster because of less render to texture overhead). oh, and as said before, you'll really want to bump up the number of passes a bit. with groups of 4, 3 or 4 passes (corresponding to n=64/n=256) are usually enough. and yeah, the idea of doing it iteratively (there's nothing recursive about this!) is pretty straightforward, but when deriving it this way, you see how to set up the zoom factors properly, which is very important for the quality of the result. if you screw that part up, you easily get visible edges, or an "uneven" look, or both.
anyway, that one generates rays that don't get darker, which sucks especially for large zooms. fixing that is easy, just lower the intensity a bit for each further pass, say multiply by a factor c (0<c<1). you'll need to take it into account when mixing the various passes and adjust it accordingly (also, you'll need to drop the 1/n). you end up using
i'll start from there for the sw way. because ideally, you don't want seperate copies at all, you want it to look like n was infinite. to simplify things, i'll just combine the zoom and darkening into a zoom-and-darken-operator S := cT. so our ideal output image would be
(normalization factor there is just to keep overall intensity the same; you can drop it if you want, then things will get brighter, how much depends on the c).
warning: some higher math required for the next few paragraphs. just skip it if you don't care.
since 0<c<1, the geometric series in the scaling factor converges and the resulting scale factor is simply (1-c). any zoom method used in practice will a) not return pixels brighter than anything in the source image, b) produce a fully white image if the input is fully white, so the norm of the zoom operator is ||T||=1 and hence ||S||=|c| ||T|| = c < 1 so the second (neumann) series also converges and our formula reduces to
which corresponds to an IIR filter with transfer function
you don't do this in HW because 3D APIs usually disallow reading from an image you're currently rendering too and also don't guarantee anything about the order in which pixels are traversed. if you do it like this, you have to guarantee that you only try to read pixels you've already rendered or the feedback won't work. you could render in concentric circles, but the 4-sheet method also guarantees the pixels you need are available and is usually a lot more efficient (and easier to code).
Code:
1/n * (x + Tx + (T^2)x + (T^3)x + ... + (T^(n-1))x)
= 1/n (1 + T + T^2 + T^3 + ... + T^(n-1)) xand you'd typically want n to be large so you don't see the individual copies. adding a lot of zoomed copies with scaled-down intensity is both slow and low-quality because of limited framebuffer precision (but still, i've seen people do it like that). what you do with hardware is assume that n=2^m (i'll use m=4 for the example, typically you want m>=6) and then use the fact that
Code:
1/16 (1 + T + T^2 + T^3 + ... + T^15)
= (1/2 (1 + T^8)) (1/8 (1 + T + T^2 + ... + T^7))
= (1/2 (1 + T^8)) (1/2 (1 + T^4)) (1/4 (1 + T + T^2 + T^3))
= (you get the idea)
= (1/2 (1 + T^8)) (1/2 (1 + T^4)) (1/2 (1 + T^2)) (1/2 (1 + T))
Applying that to an image boils down to:
- Do a 50:50 mix of the original image and a version zoomed by factor z
- Take the result, mix 50:50 with a copy of itself zoomed by factor z^2
- Take the result, mix 50:50 with a copy of itself zoomed by factor z^4
- and so on.
there's nothing holy about using 2-term groups; the main limit is the number of texture stages, really (when we first did this, there was only 2 of them). our later versions used groups of 4 (still good precision and ended up being a bit faster because of less render to texture overhead). oh, and as said before, you'll really want to bump up the number of passes a bit. with groups of 4, 3 or 4 passes (corresponding to n=64/n=256) are usually enough. and yeah, the idea of doing it iteratively (there's nothing recursive about this!) is pretty straightforward, but when deriving it this way, you see how to set up the zoom factors properly, which is very important for the quality of the result. if you screw that part up, you easily get visible edges, or an "uneven" look, or both.
anyway, that one generates rays that don't get darker, which sucks especially for large zooms. fixing that is easy, just lower the intensity a bit for each further pass, say multiply by a factor c (0<c<1). you'll need to take it into account when mixing the various passes and adjust it accordingly (also, you'll need to drop the 1/n). you end up using
- 1/(1+c) (1 + cT) in the first pass
- 1/(1+c^2) (1 + c^2 T^2) in the second pass
- and so on.
i'll start from there for the sw way. because ideally, you don't want seperate copies at all, you want it to look like n was infinite. to simplify things, i'll just combine the zoom and darkening into a zoom-and-darken-operator S := cT. so our ideal output image would be
Code:
(1 / (1 + c + c^2 + c^3 + ...)) (1 + S + S^2 + S^3 + ...) x(normalization factor there is just to keep overall intensity the same; you can drop it if you want, then things will get brighter, how much depends on the c).
warning: some higher math required for the next few paragraphs. just skip it if you don't care.
since 0<c<1, the geometric series in the scaling factor converges and the resulting scale factor is simply (1-c). any zoom method used in practice will a) not return pixels brighter than anything in the source image, b) produce a fully white image if the input is fully white, so the norm of the zoom operator is ||T||=1 and hence ||S||=|c| ||T|| = c < 1 so the second (neumann) series also converges and our formula reduces to
Code:
(1-c) (1-S)^(-1) x = (1-c) (1 - cT)^(-1) xwhich corresponds to an IIR filter with transfer function
Code:
applied along half-rays starting at the midpoint of the zoom and going outwards (or the reverse direction if your zoom factor <1), which is exactly what the standard SW method evaluates. H(z) = (1 - c) / (1 - cz)you don't do this in HW because 3D APIs usually disallow reading from an image you're currently rendering too and also don't guarantee anything about the order in which pixels are traversed. if you do it like this, you have to guarantee that you only try to read pixels you've already rendered or the feedback won't work. you could render in concentric circles, but the 4-sheet method also guarantees the pixels you need are available and is usually a lot more efficient (and easier to code).
oh, that was a reply to krabob by the way :)
The hardware accelerated way of doing this effect sucks... or better, the implementations I've seen all suck. In fact, both viagra and the nonstop experience are software rendered.
the iterative variant with a sufficient number of passes (as said, 4 if you use 4 texture stages is usually good, and 5 should be plenty even with very high resolutions) really looks pretty much perfect if you do it like i explained. the old radial blur in our fvs32 demos didn't have proper weight/zoomfactor selection so it gave the edgy look I mentioned. the candytron/werkkzeug3 variant does it correctly though (with c=1 fixed because of sheer laziness), but i don't think there's any wz3 prod with a significant amount of radial blur in it (not that i remember anyway). above by lkcc uses this method in the "leaves" (or twigs or whatever :) scene, i think also with c=1, and the quality of the blur is excellent IMHO.
you're right: above's radial blur looks good (I didn't remember that scene... I did remember the suspended man, though)
I think the combination of glow and radial blur inVariform is one of the best uses of the effect that come to my mind.
About the software way of doing it: If you want to perform bilinear sampling of the source image for the blur (and this really makes a huge difference in the visual quality) you have the problem that for all the pixels in a square region around the center (size depending on zoom factor), you need the final value of the pixel you are computing in order to compute its value. This can be solved however, by viewing the formula for the value as an equation and solving for the final value.
About the software way of doing it: If you want to perform bilinear sampling of the source image for the blur (and this really makes a huge difference in the visual quality) you have the problem that for all the pixels in a square region around the center (size depending on zoom factor), you need the final value of the pixel you are computing in order to compute its value. This can be solved however, by viewing the formula for the value as an equation and solving for the final value.
ryg: hmm is there a connection between mathematical-correctness and most-memorable ?
i just wanted to show that the two main methods are in fact closely related, even though they look different :)
Or, map picture to polar coordinates, do something like Gaussian blur along r axis, and map back again. Precalculate mappings for speed and/or use bilinear interpolation to improve quality.
I don't really know if that's faster, or gives a better result, or if it's more or less mathsy. But it's the first thing I'd try. Somehow the idea of scaling a picture multiple times disagrees with me.
I don't really know if that's faster, or gives a better result, or if it's more or less mathsy. But it's the first thing I'd try. Somehow the idea of scaling a picture multiple times disagrees with me.
