Spatial AA vs. Temporal AA

[DemoCoder]

A typical blur filter (e.g. gaussian) does not reduce aliasing, for that you need a low-pass filter.

The "motion blur" Bolloxoid keeps harping on is not a "motion blur filter", it is supersampling the original signal at a higher frequency.

 

[Bolloxoid]

Where's the problem?

There is a theoretical trade-off of spatial detail of the object itself for the lack of temporal aliasing. With adequate temporal supersampling and high frame rates it is, I'm sure, worth it.

However, motion blur is also sometimes understood as artificially creating the "exposure effect" of film running at 24 fps which is not suitable for computer games. That is the context in which motion blur is often discussed regarding CGI.

 

[Lecram25]

So you'd probably need to design the hardware specifically for it? Or could that be done on the software level?

An accumulation buffer

 

[DemoCoder]

Whether it's film, or your monitor, it doesn't matter.

Let's say I move a sphere from left to right across the screen, in a period of one second.

Let x = 1024 * t

In order to properly view this object without "blur" and without missing positions, you'd have to render at 1024 frames per second (each frame, it moves 1 pixel to the right). Whether you're using a computer screen, or rendering to film, it doesn't matter.

Since no display device (whether film, CRT, or LCD) is going to approach that refresh rate, instead, you'll have to render all 1024 frames, but you can only display 24 or 60 of them in a second, so each frame displayed will consist of approximately 16 frames blended together.

The final results
a) each frame is 16 frames blended together displayed at 60Hz vs
vs
b) each frame is 1 frame with the object moved 16 pixels in between at @60Hz

The former will look much better. Now you claim if you could "move your eyes to the right tracking the object over 1 second", you'd see superior spacial resolution. I'd argue that a) you'd see something with choppy motion (even if you could achieve it with stability, which I doubt) and second b) if you moved the mouse (your "virtual" camera or eyeball) instead, you'd have no blur and you'd gain back the spatial resolution.

If you want a better thought experiment, simply consider a retinal tracker linked to the FPS viewpoint.

In all cases, temporal antialiasing leads to better image quality.

 

[Joe DeFuria]

Anti-aliasing refers to any technique intended to reduce or eliminate aliasing...

That includes rubbing vaseline on my monitor?

Hell, Just render the entire screen purple. Complete, 100% anti-aliasing!

 

[bloodbob]

I think a good question to ask here is how much Temporal AA do we need? Carmack went off and did like 1000X sampled motion blur a while back in Q3 and he said the stills looked amazing but when watching it in motion it didn't look much better then a significantly smaller number of samples. So how many sample do you think we need? 4? 8? 16? 32? 64?

 

[V3]

The final results
a) each frame is 16 frames blended together displayed at 60Hz vs
vs
b) each frame is 1 frame with the object moved 16 pixels in between at @60Hz

I know you points.

Just out of curiousity, for interactive videogames which is better ?
a) each frame is 16 frames blended together displayed at 60Hz vs

b) each frame is 32 frames blended together displayed at 30Hz vs

c) each frame is 8 frames blended togeter displayed at 120Hz. (assuming display support all the mode and rig capable of handling everything equally)

Last time we had this discussion in console forum, Fafalada suggested that you can do a good estimation of motion blur by giving vector to each pixel to create the blur in post processing. This method is not as resource heavy as the brute force method. I thought this method could be done in either X800 or 6800.

Actually when I read Temporal AA for X800, my thought was they're really going to do something in regard to temporal aliasing, so my first assumption is old game like Q3, each frame displayed would consist of several frames blended together.

 

[ninelven]

Well anything less than 85hz gives me a headache. I'm not sure I quite understand though... would the card be blending down to a certain framerate or matching the refresh rate of the monitor. For example, could you have 16 frames blended together @ 60fps w/ a monitor refresh rate of 85hz+ or does the blending have to match the refresh rate?

 

[KimB]

Just out of curiousity, for interactive videogames which is better ?

Higher actual framerate is always going to be better, for two reasons:
1. The person's eye will not always be looking dead-center on the screen.
2. Higher framerate means less delay between input and output.

But we would really need some radically new display technology to get above ~100-200 fps, so temporal anti-aliasing really would be a good step.

As a side note, if the technique for doing temporal anti-aliasing is one in which multiple discreet frames are rendered and blended together (essentially removing the limitation of the monitor on framerate), then the best implementation for interactive scenarios would be one in which the number of frames rendered before output was variable.

Imagine, for example, for 100Hz:

while (timeelapsed < 10ms)
{
 if (firstframe)
  noblend();
 else
  blend();

 renderScene();
}

Of course, this would always result in an actual framerate below 100Hz, so it may be best to stop blending at some value below 10ms.

 

[V3]

As a side note, if the technique for doing temporal anti-aliasing is one in which multiple discreet frames are rendered and blended together (essentially removing the limitation of the monitor on framerate), then the best implementation for interactive scenarios would be one in which the number of frames rendered before output was variable.

What about the vector and pixel method, that I mentioned ?

But for brute force method, I think you can go one step better and do different sample for different objects in the scene.

For example Fafalada mentioned, that PS2 Tekken Tag is rendering the characters only not the background at double the frame rate.

 

[Simon F]

Anti-aliasing refers to any technique intended to reduce or eliminate aliasing, so I don't know where you guys are getting this "proper" definition from. A blur filter is still doing anti-aliasing because it reduces aliasing, albeit at the expense of detail.

"Blur" is not really a good term to be using. You really should say "Low Pass filter".

This LP filter should, ideally, remove all frequencies (in the spatial or temporal domain) that can not be represented in the display system (either due to the lack of pixels or due to the frame rate)

In order to do that you need to filter the higher frequencies before subsampling.

Now as it is nigh-on impossible to have either an "ideal filter" (nor to keep all the high frequencies prior to filtering) some compromises have to be made. This usually means that some 'illegally high' frequencies will still get through the filter and thus be aliased, and some wanted low frequencies will be attenuated.

 

[Simon F]

I think a good question to ask here is how much Temporal AA do we need? Carmack went off and did like 1000X sampled motion blur a while back in Q3 and he said the stills looked amazing but when watching it in motion it didn't look much better then a significantly smaller number of samples. So how many sample do you think we need? 4? 8? 16? 32? 64?

I suspect it rather depends on the amount of motion and whether you can do the stochastic sampling/(distributed ray tracing) of Cook (i.e. Pixar). The latter is pretty difficult to do in HW. The closest approach is Haeberli and Akeley's "Accumulation Buffer" but I suspect that has to do lots of passes to try to hide the correlation between sample positions/time.


EDIT: There was a paper I read which suggested ditching the idea of frames/vsync altogether and, with each time step, only rendering and updating a random "N%" of the pixels in the frame. The time step would be done at, I'd guess, 200~300Hz.

(Horrible for HW cache performance though )

 

[Ailuros]

Anti-aliasing refers to any technique intended to reduce or eliminate aliasing, so I don't know where you guys are getting this "proper" definition from. A blur filter is still doing anti-aliasing because it reduces aliasing, albeit at the expense of detail. Same with the motion blur Bolloxoid is describing. There is no requirement for anti-aliasing to add or even maintain detail.

Here's an ancient demo you can play with:

http://www.beyond3d.com/articles/v5_5500_IQ/FSAA-demo.zip

The differences between real antialiasing and a simple blur filter are more than obvious. Else put a tank of water in front of your monitor, spill some milk in it and you'll get "antialiasing" for free.

 

[bloodbob]

EDIT: There was a paper I read which suggested ditching the idea of frames/vsync altogether and, with each time step, only rendering and updating a random "N%" of the pixels in the frame. The time step would be done at, I'd guess, 200~300Hz.

Yeah thats all nice and good but of course we don't have displays that can do it at the moment either :/

 

[KimB]

EDIT: There was a paper I read which suggested ditching the idea of frames/vsync altogether and, with each time step, only rendering and updating a random "N%" of the pixels in the frame. The time step would be done at, I'd guess, 200~300Hz.

Yeah thats all nice and good but of course we don't have displays that can do it at the moment either :/

I believe the technique he's referencing doesn't have anything to do with monitor limitations. It would update only a specific percentage of the pixels in the frame each time it renders, but the output would only be sent to the monitor after a few frame updates.

 

[Simon F]

I believe the technique he's referencing doesn't have anything to do with monitor limitations. It would update only a specific percentage of the pixels in the frame each time it renders, but the output would only be sent to the monitor after a few frame updates.

Actually, I think the technique proposed sending pixels completely asynchronously to the framebuffer (i.e. there was no backbuffer at all) and so pixels could change mid-refresh.

I guess because there was no correlation between pixels you wouldn't get any cut-line artefacts. <shrug>

 

[bloodbob]

I believe the technique he's referencing doesn't have anything to do with monitor limitations. It would update only a specific percentage of the pixels in the frame each time it renders, but the output would only be sent to the monitor after a few frame updates.

Actually, I think the technique proposed sending pixels completely asynchronously to the framebuffer (i.e. there was no backbuffer at all) and so pixels could change mid-refresh.

I guess because there was no correlation between pixels you wouldn't get any cut-line artefacts. <shrug>

Bah without true high speed display you would get heaps of aliasing with motion I recon but meh.

 

[JohnH]

I thought that was primarily targeted at displays with local pixel storage e.g. TFT based LCD's etc. Although I guess iy could also be done with other technologies as well...

John.

 

[Simon F]

Bah without true high speed display you would get heaps of aliasing with motion I recon but meh.

Nothing personal but, as the paper/article was written by some of the leading graphics researchers (Bishop, Fuchs et al), I'd be more inclined to believe them than you

 

[Bambers]

Now the eye has a "sample rate" of around 25fps I think, but can detect flickering motion much higher than this, upto around 60fps IIRC (although I could swear I can tell a difference upto 120fps when playing q3 ).

the 25fps thing is a very old myth. i think it probably derives from the fact that a single cell in the retina takes around 30ms to recover after sending a signal.

There is no real limit to the fps the human eye can see, however many people will usually say they can't see more than 60-90fps because they only run their monitors at 60-85Hz. 150fps looks no smoother than 100fps when viewed on a 100Hz monitor, it looks much much smoother when viewed on a 150hz monitor.

Just out of curiousity, for interactive videogames which is better ?
a) each frame is 16 frames blended together displayed at 60Hz vs

b) each frame is 32 frames blended together displayed at 30Hz vs

c) each frame is 8 frames blended togeter displayed at 120Hz. (assuming display support all the mode and rig capable of handling everything equally)

my vote goes for c).

motion blur is a nice thing for once you've reached the maximum output of the display but before that it's pointless for interactive stuff.

personally I'd rather take single frames at 120Hz rather than 1000frames blended at 60Hz.