pouët.net

real motion blur vs timer resolution

category: code [glöplog]
 
I want to implement real motion blur, that is rendering more then 60 fps into an accumulation buffer and dumping that buffer to the color buffer every 1/60th of a second. Does any one do this? The problem i have is my timer resolution varies from 2 us to 20 us. I move my objects based off the timer and so i need to implement a timer interpolater to get a finer resolution. Is this worth the effort? For those of you why do real motion blur, iq I'm looking at you, how do you move your objects?
added on the 2013-10-02 16:47:36 by sigflup sigflup
not many demos ive seen real motion blur. however i think it (real or not) was done in Cocoon's latest demo.
added on the 2013-10-02 16:54:01 by rudi rudi
Generally, motion blur is best done with velocity buffers.
added on the 2013-10-02 17:12:26 by Gargaj Gargaj
http://www.pouet.net/prod.php?which=52982 does it like that. However, motion blur is indeed done with velocity buffers nowadays. Check it out here
added on the 2013-10-02 17:32:06 by Preacher Preacher
http://www.pouet.net/prod.php?which=61841 does the shitty "sample some frames" thing... it uses the 4 last rendered frames, makes the blur frame rate dependent. we decided to never do it again ;)
added on the 2013-10-02 17:39:52 by skomp skomp
Quote:
Generally, motion blur is best done with velocity buffers.

So much for real motion blur then. I wrote something on velocity buffer based motion blur two years ago. There are some mistakes and inaccuracies that I should fix though.
http://www.ctrl-alt-test.fr/?p=230
Now I think this is exactly sigflup doesn't want to do.

If you are using raytracing, motion blur is pretty simple in theory, as you just need to accumulate samples taken at various t + dt, while making sure they are evenly distributed over the time range. The hard part is to do so at 60fps though. Sampling means noise, so how many samples per pixel can you afford?

If you are using rasterization, then I guess you can render your moving objects n times and accumulate the light in a buffer. So it is going to cost you in terms of geometry shading and fragment shading. So how many rendering passes can you afford? (you could also use tricks to render only once static elements, and more and more times elements based on their speed, but then compositing all that is going to be a mess with depth testing and all).

In both cases you need a function p(t) that can tell you what is the position (well, transformation) of you objects for any t, not just the current one.

An example of demo doing actual sample based motion blur is:
http://www.pouet.net/prod.php?which=50131
added on the 2013-10-02 17:46:25 by Zavie Zavie
we have the option in the engine to do real motion blur, usually for baking video (as opposed to velocity based blur that we've used numerous times in demos).
tiny timesteps play havoc with our particle / physics / fluid sims, so we have the option to calculate them at fixed timesteps and interpolate. most other things are moving on keyframes or respect to time so they can be evaluated at arbitrary times.
added on the 2013-10-02 17:54:07 by smash smash
What smash said:

- If you can't just call render(arbitrary_timestamp);, use a fixed resolution for all simulation and interpolate. If you're using image feedback effects, you're out of luck
- Don't try anything fancy when accumulating the subframes; cameras are "open shutter, wait, close shutter" which is an almost perfext box filter
- Don't interpolate your timer value from one frame to the next for motion blur. Instead, place sampling points in a fixed size interval around the frame's original timer value
- Fun part I: If you wiggle the viewportaround by a fraction of a pixel for each sub frame you can fake antialiasing. Insert fixed sampling offsets / random as you like. Masagin does this for example.
- Fun part II: If you wiggle the camera's orientation/position for each sub frame, you can fake a DOF effect that's a bit noisy but shows none of the artifacts of screen space solutions :)
added on the 2013-10-02 18:03:30 by kb_ kb_
> - Don't interpolate your timer value from one frame to the next for motion blur. Instead, place sampling points in a fixed size interval around the frame's original timer value

- i forgot to mention that too. :) dont just spread the frame times evenly from frame a to b.

> - Fun part I: If you wiggle the viewportaround by a fraction of a pixel for each sub frame you can fake antialiasing. Insert fixed sampling offsets / random as you like. Masagin does this for example.

and that :) although we have a separate path for this that just resubmits the draws and doesnt do any simulation etc. for our cases where there's heavy simulation and you just want some more aa on the video this can be a lot faster.
while doing this we add some jitter to pretty much anything that uses noise and suffers from undersampling: shadow maps, ao/gi, volumetric fx, dof, etc etc.
added on the 2013-10-02 18:18:22 by smash smash
thank you everyone for the tips! Interpolating sample points in frame's original values is what I'm doing now
added on the 2013-10-08 04:46:34 by sigflup sigflup
> - Fun part I: If you wiggle the viewportaround by a fraction of a pixel for each sub frame you can fake antialiasing.

You can do this across single-sampled frames as well, and your monitor will (...may) integrate for you ;)
added on the 2013-10-08 10:24:26 by hornet hornet
I sometimes did implement real motion blur. My main problem was with the fillrate so it's not feasible to do it in realtime.

So yeah, velocity buffer and other methods are favorable.

ReText uses real motion blur with that wiggle antialiasing smash described for the interference, zoomer and a few more effects, here I had a 80x50 framebuffer so fillrate wasn't a problem anymore. 1Ghz was enough to do it and still have great framerate.
added on the 2013-10-08 21:53:57 by musk musk

login