Whats Wrong with Epic? Anti Aliasing Technology and Terrible FXAA Quality!!

[Nick]

I’ve been interested in ways to minimize the ghosting that comes with UE4’s out-of-the-box TAA solution as well. I’ll have to check out Hallatore’s method, but in the meantime I recently read Guerrilla’s recent Siggraph presentation on how they handled high quality, responsive AA for Horizon:ZD. They achieve a stable, responsive anti-aliased result using only 2 frames of data (TAA) along with FXAA and some subtle sharpening, which put together gives a very clean result on what would otherwise be extremely noisy sub-pixel hairs and foliage pixels. From what I’ve played of the game, there’s no noticeable ghosting, and the entire setup is silky smooth on old standard PS4 hardware. I’m interested in seeing if Epic ends up implementing some of this responsive AA methodology to future engine updates.

Here’s a link to the presentation, and down at the bottom of the page you can download their full 300mb Powerpoint presentation with all the presentation notes.

Decima Engine: Advances in Lighting and AA - Guerrilla Games

The AA stuff start on page 30. Here are a couple excerpts from the PP notes on pages 37 and 38:

So TAA helped us a lot. But getting that to work RELIABLY was somewhat of a challenge.

That’s because all TAA implementations depend on some form of history reuse.
And this is typically done by accumulated many frames over times, and that CAN work great.
But doing that didn’t work that well for Horizon.

The reason for that is that our AA is applied on often very thin geometry,
Plus we apply AA only AFTER we already overlayed a lot of visual FX and all post effects.
And that includes effects life Depth of Field and vignetting.

And lastly, we base our TAA reprojections on a HALF-RES motion buffer, which is probably not ideal.
And some types of objects don’t even output motion vectors at all.

So, for those reasons, we prefer not to use any previous frame for too long.
And so, instead of somehow accumulating the output from previous frames,
we chose to only reuse the INPUT to the AA system from the previous frame, but not the previous output.

That is, we use the raw render of the previous frame and the current frame, but nothing more.
Thay way, we prevent any long ghosting trails caused failed rejects,
and we reach a stable and final result in only two frames, making our technique very responsive.