Hardware Motion Blur - yay or nay ?

[OpenGL guy]

That's not enough, though. To show this point, just wave your hand between your eyes and your monitor. You won't see a smooth blur like you would if you waved it between your eyes and some non-flickering object. But no matter what your refresh rate, you'll not see a smooth blur, but instead a large number of discreet copies of your hand as your monitor flickers (this requires a CRT to work). This is one example of temporal aliasing, and how rendering discreet frames is not realistic.

Not all monitors flicker.

 

[Bolloxoid]

I'd rather have faster frame/refresh rates and let my eyes do the rest.

Of course we all would like that. But CRTs are practically capped at 100 Hz and LCDs are usually designed for 60-Hz adapter refresh so what can you do? Given these limitations you need to star looking at temporal antialiasing techniques to improve things.

 

[Bolloxoid]

To show this point, just wave your hand between your eyes and your monitor. You won't see a smooth blur like you would if you waved it between your eyes and some non-flickering object. But no matter what your refresh rate, you'll not see a smooth blur, but instead a large number of discreet copies of your hand as your monitor flickers

Obviously, increasing the refresh rate enough will eventually make the temporal aliasing effect smaller than the spatial resolution of vision, solving the problem.

 

[KimB]

Not all monitors flicker.

Yes, some have rather slow phosphors. But most do flicker, particularly at lower refresh rates (< 85Hz).

 

[KimB]

Obviously, increasing the refresh rate enough will eventually make the temporal aliasing effect smaller than the spatial resolution of vision, solving the problem.

Smaller, yes. Solving the problem? No.

Consider we're running at 640x480 (this is better for temporal aliasing), and 200 fps on a monitor with 200Hz refresh rate.

In order to eliminate temporal aliasing entirely, I can have nothing move by more than one pixel per frame. That means nothing can move from the left of the screen to the right of the screen in less than about 3.2 seconds. That's an absurdly long time, and many objects on the screen move much, much more quickly than that.

High framerates cannot hope to come close to solving the temporal aliasing problem.

 

[OpenGL guy]

Yes, some have rather slow phosphors. But most do flicker, particularly at lower refresh rates (< 85Hz).

Phosphors? My LCD don't have no stinkin' phosphors

 

[KimB]

I did explicitly state you need a CRT

 

[KimB]

Chalnoth, Mintmaster - I have a question for you guys - how does this method handle visibility changes? Even with linear (velocity only displacements) blur, it seems to me that the order in which the generated quads are "added to output" matters...

Well, for things that are moving into the frame from outside, that's not really a problem: the CPU still knows where the object was in the previous frame, it just wasn't (necessarily) sent to the graphics card.

For objects that were either just spawned (ex. a rocket fired from a rocketlauncher), or objecs that were occluded and now no longer are, things get a little bit more interesting.

For newly-created objects, you could use the instantaneous velocity from the physics information in lieu of the average velocity from the displacement (from my idea), or, if you were using the instantaneous velocity all along anyway, this just isn't a problem.

Occluded objects, however, are much more difficult. One could just ignore this, and depend upon high framerates to make the artifacts less noticeable. Or, if working in pre-perspective-transform space as I stated previously, you could attempt to make use of the z-buffer during the motion blur pass. But it would be nontrivial to detect when objects should be occluded, as many would be highly transparent (parhaps a conditional z-buffer write in the situation where the pixel moved less than X amount between frames?).

 

[Bolloxoid]

Consider we're running at 640x480 (this is better for temporal aliasing), and 200 fps on a monitor with 200Hz refresh rate.

You didn't say 200 Hz in the post I replied to, you said "no matter what" refresh rate.

In order to eliminate temporal aliasing entirely, I can have nothing move by more than one pixel per frame. That means nothing can move from the left of the screen to the right of the screen in less than about 3.2 seconds. That's an absurdly long time, and many objects on the screen move much, much more quickly than that.

Yes. I was merely suggesting that there is a theoretically sufficient refresh rate for a given spatial resolution and velocity, something you seemed to be denying with your "no matter what" comment. I am not arguing against the need for temporal antialiasing in practice.

 

[KimB]

You didn't say 200 Hz in the post I replied to, you said "no matter what" refresh rate.

Right. And 200Hz is nearly as high as it gets. Hence, "no matter what."

Yes. I was merely suggesting that there is a theoretically sufficient refresh rate for a given spatial resolution, something you seemed to be denying with your "no matter what" comment. I am not arguing against the need for temporal antialiasing in practice.

Sure, theoretically sufficient but practically impossible to reach. Even if you got a monitor and video card that could do 1000Hz refresh rate, I could find a game scenario that would still show temporal aliasing.

 

[OpenGL guy]

Sure, theoretically sufficient but practically impossible to reach. Even if you got a monitor and video card that could do 1000Hz refresh rate, I could find a game scenario that would still show temporal aliasing.

Stop stealth editing! 1000 Hz isn't really a problem for memory bandwidth if you're at 640x480.

 

[KimB]

Stop stealth editing! 1000 Hz isn't really a problem for memory bandwidth if you're at 640x480.

Sorry I edited because I realized that it actually wouldn't even be that horrendous for 1600x1200. It'd take about 7.6GB/s at that res, which would be a very significant performance hit, but is doable (though 1000fps is not, for any realistic gaming scenario).