pouët.net

Decent motion blur?

category: code [glöplog]
What's the best way to produce post processing motion blur?

I'm just taking a few samples on the direction of the displacement vector. Is there some better technique?
added on the 2010-08-31 01:22:10 by xernobyl xernobyl
Render motion vectors into render-target, blur along motion vector in screen space?
added on the 2010-08-31 02:21:21 by kusma kusma
yes that's what I'm doing... is there anything better?
added on the 2010-08-31 03:24:00 by xernobyl xernobyl
if the demo is light, you can render many subframes and average...
added on the 2010-08-31 03:47:50 by iq iq
How about this approach: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch27.html ?
added on the 2010-08-31 08:44:29 by kbi kbi
Everything looks better after a good portion of C2H5OH.
added on the 2010-08-31 12:36:15 by trc_wm trc_wm
kbi: How is that approach different?
added on the 2010-08-31 13:10:43 by sagacity sagacity
xernobyl: I don't know of any other way of doing motion blur as a post process, but I'd try to do multiple passes of blur (i.e blurring the blurred result etc). That might make occlulsion-problems less obvious.
added on the 2010-08-31 13:19:59 by kusma kusma
plainoldsagacity: Relating to whose answer? :) I suppose it's close to what kusma has suggested, but provides motion vectors in quite a clever way, which is why i mentioned it.
added on the 2010-08-31 14:04:36 by kbi kbi
for scenes with many colors:

Code:const float steps = 16.0; vec2 xy = gl_TexCoord[0].xy; vec3 dir = normalize(-1.0+2.0*texture2D(color, xy).rgb)*0.25/steps; vec3 color = vec3(0.0); for (float i = 0.0; i < steps; i += 1.0) { color += texture2D(color, xy).xyz; xy += dir.xy*dir.z; } gl_FragColor = vec4(color/steps, 1.0);


This will produce a motion blur that doesn't have anything to do with reality and therefore is very suitable as a proper demo/intro effect.

Hint: For an even more special effect you can modify the dir variable in inner loop and have an even greater impact for the viewer as he/she tries to understand what is going on the screen.
added on the 2010-08-31 14:07:53 by pommak pommak
Cheap fake: Calculate motion vectors (i.e. redraw the scene using x,y deltas from prev frame as color) and use those to do a directional blur. You may want a blur that varies writing position rather than texture reads though.

Overkill: Jitter samples in time with a known block pattern. For each block, do some covariance magic to find the principal axes and use that to perform delaunay tetrahedralisation in transformed areatime. With that you can estimate the pixel value at any x/y/t location and thus the integral as well.
added on the 2010-08-31 14:11:09 by 216 216
216: No, THIS is what I call overkill! 5d rasterization beats 3d rasterization any day!
added on the 2010-08-31 14:28:11 by kusma kusma
Go cutting edge!
http://graphics.cs.williams.edu/papers/StochasticHPG10/
(sorry, I'm a bit hyper after listening to Smash's arttech-talk)
added on the 2010-08-31 15:15:10 by hornet hornet
Kusma, add brdf, aperture, wavelength and tree branch to those three and you realize why there's no tgr4 or gamma3 ;)

But back to realism. What standard recursive directional blur does is:

1. (for..) newpixel[pos] = (pixel[pos-motion[pos]*k]+pixel[pos+motion[pos]*k])*.5;
2. k *= .5 and goto 1 until smooth enough.

But what you need is something like:

1. (for..) newpixel[pos-motion[pos]] += pixel[pos];
2. (for..) newpixel[pos+motion[pos]] += pixel[pos];
3. normalize pixels
4. k *= .5 and goto 1 until smooth enough.

Troubleshooting:

1. How: Polygon mesh, vertex shader.
2. Slow: Use bigger triangles.
3. Ugly: Use method 2 to blur just the motion vectors and go back to method 1 for pixels.
4. Work: ok, just render the scene several times and forget PP. You get AA as a bonus if you jitter the samples.
added on the 2010-08-31 16:18:03 by 216 216
5d rasterization? what?
Smash?
arttech-talk?
I DEMMAND URL!
added on the 2010-08-31 18:20:47 by abductee abductee
Url for Smash 2010 Assembly Talk: vimeo.com/14458079
added on the 2010-08-31 18:25:13 by emoon emoon
haha, omg, smash knows a lot of graphics programming buzzwords :)
Key statements:

Smash: "And how does it look?"
Decipher: "Shit. It looks like shit so far."
Smash: "Words of encouragement..."

XD
added on the 2010-08-31 21:09:05 by ferris ferris
It's all a bunch of dots? I knew it!
added on the 2010-08-31 22:48:51 by doomdoom doomdoom
hornet: is that talk available anywhere? I tried searching last week but found nothing.
added on the 2010-09-01 01:38:46 by Claw Claw
Hey insectecutor, read the thread shit head.
added on the 2010-09-01 01:39:06 by Claw Claw
it's fun to watch navis talk directly after smashs talk
added on the 2010-09-01 08:22:53 by pandur pandur
hardware motion blur : record the video with a 30 fps VGA webcam. show the video live on another screen.
added on the 2010-09-01 08:52:57 by zerkman zerkman
For semi-decent camera-movement only motionblur, see Valve's description here:
http://www.valvesoftware.com/publications/2008/GDC2008_PostProcessingInTheOrangeBox.pdf

- otherwise as kusma said, the most common is motionvectors: the description in this (otherwise not recommendable) book of motion-vector motionblur looks pretty solid. This version is a bit slow though, so he ends up using classifying different screenspace areas to speed it up.
added on the 2010-09-01 11:03:29 by hornet hornet

login