
Aliasing and you - BIackSwan
http://www.codinghorror.com/blog/2011/12/fast-approximate-anti-aliasing-fxaa.html
======
jaylevitt
Interesting... in audio, we've basically had affordable super-sampling for a
few years. That's exactly what "record at 96KHz or 192KHz" is; all your
plugins run against a waveform that's higher-bandwidth than you can hear, and
then you downsample and dither at the end to 44.1 or 48KHz in mastering. Some
of the best equalizer plugins had internal upsampling, so that even if your
source material was 48KHz, the processing was all done at 96KHz. The quality
gain from the higher resolution offset the quality loss from resampling.

(In audio, there are other benefits to higher resolution, like latency; a
256-sample buffer adds 6ms at 44.1KHz, but only 1ms at 192KHz.)

~~~
daeken
> (In audio, there are other benefits to higher resolution, like latency; a
> 256-sample buffer adds 6ms at 44.1KHz, but only 1ms at 192KHz.)

But the buffer is there to allow you to gather data up before sending it
across the pipe (physical or virtual) so you're not incurring latency you
don't need to. Increasing the resolution of your data doesn't decrease
latency, as you're just incurring that hit more frequently. If that worked,
you could just do away with the buffer and send a continuous stream of data at
whatever sampling rate you wanted.

~~~
jaylevitt
I'm thinking of setups which often have some absolute minimum buffer size,
maybe due more to the protocol (e.g. ASIO) than the converter design; my RME
Digiface setup can't work below 56 samples, no matter what the sample rate.

~~~
klodolph
Don't forget that the air between you and the speakers is another buffer,
holding about 150 samples at 44.1 kHz, assuming near field monitors.

~~~
jaylevitt
Yep, which is why it's so amazing that bands play to a beat that doesn't
really exist - it's an agreed-upon moment in time that we pretend is the same
for all of us, but when you're standing 20 or 30 feet apart, it isn't.

But latency is critical for tracking through headphones, especially singers; a
little bit of latency can screw up your pitch perception as well as your
timing.

~~~
klodolph
Well, that's why we have hardware monitoring. You only really need the low
latency stuff for recording software synthesizers / samplers or if you have a
virtual amp, etc.

------
daeken
FXAA is neat, but the idea of using pixel-based edge detection on games is,
IMO, a bit silly. Why not use detect edges on the _depth_ buffer? You'll much
more easily see the contrast and you will be far, far less likely to blur your
textures. I might have to whip up a quick WebGL demo of this.

~~~
hormis
FXAA and other similar techniques are only relevant when dealing with deferred
rendering only. Detecting edges on the depth buffer may sound as the solution
until you realize that two planes at right angles has an edge between that can
alias. The change there is in the normal and not the Z.

Also modern graphics cards do not give programmatic access to the z-buffer as
the z-buffer format is often proprietary. Deferred shading based renderers
often duplicate the z-value also into a texture.

Deferred rendering can render large number of dynamic, unshadowed lights very
efficiently. It can be used as approximate global illumination technique.

~~~
daeken
> FXAA and other similar techniques are only relevant when dealing with
> deferred rendering only.

Why is that? While techniques like FXAA are needed for deferred rendering due
to the order of operations, I don't see why FXAA isn't acceptable on non-
deferred renderers.

> Detecting edges on the depth buffer may sound as the solution until you
> realize that two planes at right angles has an edge between that can alias.
> The change there is in the normal and not the Z.

If you have two planes at a right angle to each other, you'd see that in the
depth buffer. Imagine you're looking at a line of pixels and you're doing this
on each pixel -- you'd look to see if the pixels on either side of the one
you're on are trending in opposite directions from the current one, and know
it's an edge.

> Also modern graphics cards do not give programmatic access to the z-buffer
> as the z-buffer format is often proprietary.

As far as I'm aware, all modern graphics cards allow you to render the depth
buffer to texture just like the color buffer.

> Deferred rendering can render large number of dynamic, unshadowed lights
> very efficiently. It can be used as approximate global illumination
> technique.

Sure, but there's no reason you can't do post-AA using the RTT depth buffer
and your composited color buffer.

~~~
hormis
> Why is that? While techniques like FXAA are needed for deferred rendering
> due to the order of operations, I don't see why FXAA isn't acceptable on
> non-deferred renderers.

FXAA is acceptable for the other techniques as well. However, MSAA is, in my
opinion, a better technique as it uses supersampling at the edges and is
already hardware assisted. FXAA's strength is that it is less expensive than
MSAA memory and bandwidth wise. Both are a premium in deferred shading as you
are using a 4x RBGA16 texture render target or something close to it :)

> If you have two planes at a right angle to each other, you'd see that in the
> depth buffer. Imagine you're looking at a line of pixels and you're doing
> this on each pixel -- you'd look to see if the pixels on either side of the
> one you're on are trending in opposite directions from the current one, and
> know it's an edge.

The question is can you get reliable edge detection with less number of
texture look-ups on the z-buffer versus the RBG based edge detection?

> As far as I'm aware, all modern graphics cards allow you to render the depth
> buffer to texture just like the color buffer.

Not quite. You can render the z value to a texture, but that is done in the
pixelshader and do not touch the hardware z-buffer used for z-fail/z-pass
tests. It is this hardware z-buffer that is inaccessible, as it shares it
memory with the stencil buffer which is used for stencil tests. Hence the
proprietary format.

> Sure, but there's no reason you can't do post-AA using the RTT depth buffer
> and your composited color buffer.

See [http://msdn.microsoft.com/en-
us/library/windows/desktop/bb14...](http://msdn.microsoft.com/en-
us/library/windows/desktop/bb147221%28v=vs.85%29.aspx)

> All render target surfaces used together must have the same bit depth but
> can be of different formats, unless the D3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS
> cap is set.

As you can see, the bit depth restriction means that you would end up with 2x
bandwidth usage with the z based edge detector, especially on the older
hardware where you do not have the bandwidth to spare. It would be a different
case if you can sample the hardware z-buffer.

~~~
daeken
> The question is can you get reliable edge detection with less number of
> texture look-ups on the z-buffer versus the RBG based edge detection?

The way it's working in my mind has about the same number of lookups as FXAA,
but I'm honestly not sure how that'd pan out in practice. We'll see.

> As far as I'm aware, all modern graphics cards allow you to render the depth
> buffer to texture just like the color buffer. Not quite. You can render the
> z value to a texture, but that is done in the pixelshader and do not touch
> the hardware z-buffer used for z-fail/z-pass tests. It is this hardware
> z-buffer that is inaccessible, as it shares it memory with the stencil
> buffer which is used for stencil tests. Hence the proprietary format.

No need for the internal format, though -- raw depth buffers are A-OK.

> As you can see, the bit depth restriction means that you would end up with
> 2x bandwidth usage with the z based edge detector, especially on the older
> hardware where you do not have the bandwidth to spare. It would be a
> different case if you can sample the hardware z-buffer.

One thing to keep in mind is that yes, you're rendering it to texture and you
incur _some_ overhead there, but you don't have to pull that data back to the
CPU so you're dependent on bandwidth between the GPU and its memory, not main
memory. Sure, it's double the memory used there, but that's negligible from a
bandwidth perspective. Also a good thing to note that you generally already
have your depth buffer if you're doing deferred rendering, and you can do all
the AA based on that, in theory.

~~~
hormis
> he way it's working in my mind has about the same number of lookups as FXAA,

However, the FXAA will have a clear win as it works over a partly transparent
polygon. So you will have to combine both an RBG and z based to get the same
result as an FXAA.

> you're dependent on bandwidth between the GPU and its memory, not main
> memory.

The bandwidth I was talking about was the older cards which do not have
bandwidth or fill rate to keep 60fps with deferred shading, no AA. FXAA would
be a candidate there if it is a pure RGB technique on the composited frame,
especially as it is cheaper than MSAA.

------
dazbradbury
SMAA is even better and faster than FXAA. <http://www.iryoku.com/smaa/>

Also there is software that automatically injects SMAA into your d3d9, d3d10
or d3d11 games: <http://mrhaandi.blogspot.com/p/injectsmaa.html>

_Pulled directly from codinghorror comments, posted by: Mārtiņš Možeiko_

~~~
rsanchez1
I was hoping someone else would say that. Have you really tried SMAA? What is
your opinion of it on a few games?

------
luchak
I thought it was a little odd that he says the proper way to solve the problem
is to have a higher-res screen, just before he says that we can't do super-
sampling because it's too expensive.

~~~
ConstantineXVI
High-res screen: expensive[money]

Super-sampling: expensive[cpu]

~~~
daeken
A high-res screen isn't just expensive money-wise -- at the resolutions you
need to avoid AA techniques, you're rendering at the same resolution you'd be
rendering at _for_ AA techniques. So it's more expensive in terms of money and
in CPU/GPU time.

------
burgerbrain
I guess I'm probably the only person in the world that prefers the look of no-
AA...

~~~
zyb09
Most of the time, you loose the "crispness" of the final image with AA and
everything tends to look a little bit blurry. Couple that with fact, that it
drops the FPS by quite a bit and over time I got slowly conditioned against
AA. However in some games it looks very good. WoW for example has a much
better image quality with AA. Of course it also runs with 60 FPS pretty much
everywhere.

------
ck2
That was a good primer for a non-gamer like me.

Can it be used to make flash graphics and webgl lower load too?

~~~
exDM69
I don't know about Flash, but I'd say this is a bit unlikely. You need special
shader programs for custom antialiasing tricks like FXAA.

For WebGL, you should be able to write the shaders and a multi-pass renderer
framework that does the antialiasing. However, with WebGL, you're constrained
to using somewhat simpler texture formats than you have available with a
modern desktop. If you have to use 8 bit RGBA textures, you will probably
suffer from color banding and other nasty artifacts compared to 16 bit
floating point textures that are normally used on the desktop.

------
ricardobeat
Amazing. I always thought that something better than super-sampling had to
exist.

I hope this becomes standard on PS3 titles, it's painful seeing all those
ragged edges on screen, knowing you have a few gigaflops of processing power
sitting there, doing nothing :(

~~~
maximilianburke
A number of PS3 titles use a technique called morphological anti-aliasing
(MLAA) which is more computationally expensive than FXAA but can look better
(to art directors and rendering engineers anyways :)) and, because it runs
well on the SPUs, it is able to offload the GPU for it to begin on its batch
of work.

------
john2x
Huh, I've always thought that that was how anti-aliasing in games worked; take
the entire scene and smooth it, Photoshop filter style.

TIL.

------
jQueryIsAwesome
If you are going to analyze all pixels on the screen, it would be better to
use some kind of median filter[1].

It looks smoother and more focused: <http://i.imgur.com/hsq84.jpg>

[1]<http://en.wikipedia.org/wiki/Median_filter>

~~~
malkia
Median filter has to sort pixels (3x3, or 5x5) and get the median (this is by
memory, haven't looked at wikipedia). As such it might be or might not be
better solution.

Also it can't be done in-place (or can it?)

~~~
regularfry
You could do it in-place with a memory cost of one pixel row (for 3x3, or two
for 5x5) plus one (or 2) pixels. That might make be worthwhile depending on
where you're actually doing it. It _might_ be more efficient - it's worth
implementing both to see.

------
DannoHung
Am I like the only person in the world who hasn't been able to see jaggies in
like.. 6 years?

