Realtime true (real) Motion blur

Started by
13 comments, last by LorenzoArchidea 18 years, 1 month ago
I was wondering what is the different between fake-blend-over-the-last-frame and true, real type of motion blurs ? Thank you.
----My dev blog: http://slypot.com/blog
Advertisement
Motion Blur

John B
The best thing about the internet is the way people with no experience or qualifications can pretend to be completely superior to other people who have no experience or qualifications.
I guess a "true" motion blur would be done with an acclumulation buffer, rendering many discrete versions of the scene between the previous and current frames, in order to simulate the nature of a camera shutter. Blending in the previous frame doesn't really work since it's not the data your interested in, you need all camera relative movement from the previous frame to the current one.

However, for a real-time app, anything which approximates this behaviour could be considered true motion blur. Some next gen games are starting to feature motion blur as a post process, where a fullscreen buffer filled with velocity data is rendered out per frame, and then used to blur the final scene. Have a look at www.projectoffset.com for a good example of realtime motion blur.

T
Quote:Original post by Tessellator
Have a look at www.projectoffset.com for a good example of realtime motion blur.

T


And for details on how to do that, or something pretty similar to that...see your latest installment of the DirectX SDK. :)
One thing to watch out for with the DX sample (which caught me out) is that they do their divide by w in the vertex shader (when converting to screen space). This works okish most of the time, but when you get the camera close to a surface you'll see lots of distortion because the values can't be linearly interpolated (once you divide by w, you're no longer in a linear space). It is better to do the divide by w in the pixel shader (at least in my experience).

T
There is a detailed explanation relating to how Valve implemented "real" but not real-time blur for Day of Defeat here.

True blur is basically an optical illusion, a defect in vision and camera frame capturing methods. It's crucial for movies however (due to it's "temporal anti-aliasing") and one of the primary reasons why they look great in a dark theater at 24 fps.
"Artificial Intelligence: the art of making computers that behave like the ones in movies."www.CodeFortress.com
Quote:Original post by Tessellator
It is better to do the divide by w in the pixel shader (at least in my experience).

T


I too find this to be the case a LOT more often than not for values that need to be divided by w (depending on the application and what it is you're trying to do).

In sucks, because when being forced to do it in the pixel shader, you're chewing up x # of instructions out of your 64. :| (That is of course if you're using 2.0 hardware).

[Edited by - Brian Lawson on March 17, 2006 10:02:45 AM]
Theory-correct Motion blur can be achieved using Accumulation butter. Render many frames into the accumulation buffer then bring it onto the screen. Without accumulation buffer, you can also render to texture many times then put a quad onto the screen with that texture. This approach may suffer from limited accuracy of texture if you don't use floating-point texture, or loss of quality from texture filtering.
Hmmm... I found that accumulation buffer would be far to slow for a use in games (or I'm wrong and nowadays hardware could handle this?).
Maybe I could just add some blur for "Frame Feedback Motion Blur" texture and get a pretty similar results as a real-motion blur?

Thanks.
----My dev blog: http://slypot.com/blog
If you can afford requiring floating point texture render targets for your motion blur effect, go with the "real" one - do the temporal vertex morphing in the vertex shader and render the temporal antialiasing samples to high-precision floating point textures with GL_EXT_framebuffer_object and GL_ATI_texture_float (for ATI cards) or GL_NV_float_buffer (for NVIDIA cards). It should work at a reasonable speed, unlike the accumulation buffer method.

I'd strongly advise against going with frame feedback - I have tried it for a couple of my demos and - well, just like everybody else says, it looks horrible. So don't and instead opt for the real essence of motion blur.
Olli Salli

This topic is closed to new replies.

Advertisement