A comparison of motion blur implementations *spawn

I always thought Kingdoms of Amalur's motion blur was well done. Certainly for a seventh gen game.
Maybe it's because I played it right after Alan Wake with its ugly motion blur.

Google reveals a lot of people complaining about it, but those all seem to be for the PC version (and half of those idiots are actually complaining about bloom lighting and using the wrong terminology). The X360 blur was subtle and only occurred during fast camera rotation.
 
What techniques are there to avoid "crap blur" (I think you just coined a new phrase, Shifty)?
I'm serious. I'm going to call that "crapping" from now on.

So, my question is why does crapping happen and what blur methods are crapping free?
 
It's applied per object with a velocity vector being used to determine how to blur the pixels. The silhouette is caused by disparities in adjacent pixels - the near object is moving faster and the background not, so the near object's pixels are blurred but not the background's. The solution is to use magic. Or science. Okay, here's where my knowledge runs out. ;) On PS2 and other brute-force methods you'd draw the scene in multiple intervals, which was more trails than motion blur but it worked okay. I don't know how motion vectors are handled across object borders.
 
the near object is moving faster and the background not, so the near object's pixels are blurred but not the background's.
Thanks for the explanation. :) That's what I thought, only the pixels of the moving object are blurred.

On PS2 and other brute-force methods
Teh CELL... Seriously, I remember how the motion blur in games like GOW III was praised and I wonder why, a generation after that, we still have to deal with crapping in motion blur.
 
Maybe... for titles with temporal AA ( previous frame data) -> pixels that are normally marked beyond threshold (to avoid ghosting) can have MB applied instead and help blend in with the object?

Might need to look at how Doom's blur behaves with TAA on/off or something.

Crysis had some old method of handling edge pixels with the velocity mask to help it more, but that's pretty old.
 
Hahaha, yes, but IF you use motion blur, what methods avoid crapping? Examples?
The best motion blur I have ever seen is the one used in Driveclub. With the Pro Boost They revealed that the quality of MB is dynamic, depending of GPU load.

Example of Driveclub MB:

fPrFtLJ.png
 
^Nice example.

I'm still reading throught this thread. What I haven't found yet is what causes crapping. I understand that it's an effect from OMB (right?), but I don't understand why the pixels of the silhouette are not blurred, too, if the silhouette moves too...
 
The "sharp edges" artifact happens because games track velocity per-pixel. So if a pixel has high velocity it gets blurred along the movement direction, if not the pixel remains untouched. So at object edges you will get a sharp transition from "really blurred" to "not blurred at all" for cases where an object is moving quickly across a static background. To fix this, your pixels need to know when their neighbors are being blurred, and then they need to grab those moving pixels so that they're "smeared" on top of the static pixels. One common way to do this is to do some kind of image pass on the velocity buffer that dilates the velocity values, so that they bleed onto neighbors. In this paper they get around the issue by computing the maximum velocity for each 16x16 tile of pixel, and all pixels within that tile search along the velocity direction for moving pixels.
 
The "sharp edges" artifact happens because games track velocity per-pixel. So if a pixel has high velocity it gets blurred along the movement direction, if not the pixel remains untouched. So at object edges you will get a sharp transition from "really blurred" to "not blurred at all" for cases where an object is moving quickly across a static background. To fix this, your pixels need to know when their neighbors are being blurred, and then they need to grab those moving pixels so that they're "smeared" on top of the static pixels. One common way to do this is to do some kind of image pass on the velocity buffer that dilates the velocity values, so that they bleed onto neighbors. In this paper they get around the issue by computing the maximum velocity for each 16x16 tile of pixel, and all pixels within that tile search along the velocity direction for moving pixels.
Thank you very much for your explanation on the crapping issue.

Fact is, I don't remember that happening in older games (I mean, PS and PS2 games), even though the blur method was less advanced. I guess blur just blurred all the screen every time there was motion. Is that the reason?
 
PS and PS2 didn't have blur. They had repeated overdraw of the past few frames, and, yes, as you say, applied to the whole screen every time. If the motion was fast enough then you got ghosting, and softer blurs with more frames meant a really unrealistically slow 'shutter'.
 
PS and PS2 didn't have blur. They had repeated overdraw of the past few frames, and, yes, as you say, applied to the whole screen every time. If the motion was fast enough then you got ghosting, and softer blurs with more frames meant a really unrealistically slow 'shutter'.
I remember this PS game, but I can't quite remember the title... It was a futuristic racer, kind of a Wipeout but the vehicles didn't float and resembled a quad. The tracks had loops. I remember it featured some names from the horoscope.

Well, I remember this game had this effect and I liked it a lot.
 
Back
Top