Jump to content
  • Advertisement
Sign in to follow this  
Daver

Realtime true (real) Motion blur

This topic is 4475 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was wondering what is the different between fake-blend-over-the-last-frame and true, real type of motion blurs ? Thank you.

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
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. :)

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!