Full screen anti-aliasing is an effect where your graphics card renders everything at a larger size and scales it down.  The result is that jagged 1-pixel stair-step edges on polygons become soft and blended.  Without FSAA, mountains look jagged, and the edges of wings can “swim”.

The terminology “2x” FSAA or “4x” FSAA refers (roughly) to how many more pixels are used to draw polygons when FSAA is on.  In other words, 4x FSAA is the equivalent of making your image twice as tall, twice as wide (that’s 4x the pixels, hence 4x) and then sizing it down by a factor of two.  The result is that a stair-step edge will gain 4 levels of translucency to smooth it out.  (In practice, the GPU vendors are very clever about not just doing 4x or 16x the work – so you might pick 16x FSAA and not pay a 16x fps cost.)

There are a few things you should know about FSAA:

  • It makes images look a lot better, to the point where most of you won’t run X-Plane without it.
  • It happens entirely on the graphics card.  We just say “make it so” and it happens.
  • It’s really very fast for all of the work it does.  The GPU companies have spent a lot of effort on improving FSAA performance – see the above comment about being clever.
  • It doesn’t work with deferred rendering.

That last point is a bit of a problem for X-Plane 10, as well as pretty much every other modern game engine in the universe.  Deferred rendering is what powers X-Plane’s new global lighting, and it has become the standard for real time rendering.  Sadly, the two pass rendering scheme of a deferred renderer doesn’t work with hardware FSAA.

Fortunately, since this is a problem for everyone, and not just us, the GPU companies have started working on the problem, and they’ve come up with some very clever stuff.  In particular, FXAA.

X-Plane 10 will have two optional ways to anti-alias a deferred scene:

  • FXAA, which operates as a post-processing pass on the entire scene.  What’s good about FXAA is: it anti-aliases everything – texture sampling and alpha as well as polygons, and it’s very fast.*
  • 4x SSAA (super-sampling) – basically we just draw everything twice as big and then size it down.  This will hit your fps – X-Plane is doing putting 4x load on your GPU.  The advantage of 4x SSAA is that it anti-aliases texture-alpha cut-outs, something that FXAA can’t do (because the image is already broken by the time FXAA runs).

Here is a comparison: this is an area around KSEA at sunset in X-Plane 10; it’s a debug build but I’ve turned off all of the 3-d to keep fps up.  The fps you’re seeing are almost entirely a function of graphics card fill rate, so it will give you some idea of the relative costs of these algorithms.

Here we have no anti-aliasing – notice the jaggies on the mountains in the distance.
Here we have 4x SSAA.  The mountains look better but not great – it’s only 4x.
Here we have FXAA.  It does a pretty good job of smoothing out the mountains at very little frame-rate impact.
Full screen anti-aliasing aims to smooth out jaggy lines created by polygons. Normal full-screen anti-aliasing does not improve jaggy lines created by alpha-tested geometry (that is, geometry where the ‘shape’ is created by a binary keep/kill decision based on the alpha channel of a texture).  So no amount of FSAA is going to help smooth vegetation and fences, for example.

This scene shows a fence – the fence is “cut” using alpha testing – that is, the links are not polygons, but rather alpha spaces in the texture.  As a result, when we get far enough away that the cutouts are < 1 pixel, we get nasty aliasing.  You can also see the railing on the top of the control tower missing part of its geometry due to aliasing.
In this picture, we are rendering with 4x SSAA.  This means that while the cutouts are too small for us to see on screen (the cutouts are < 1 pixel), they are actually two pixels when originally rendered; the SSAA shrinks them down after the cutout is done, resulting in a much nicer look.  The tower railing (since it was rendered at double the res) is also now visible.
This is the same image with FXAA.  Since FXAA is a post process, FXAA can try to smooth out the results, but fundamentally the information about the fence cutouts was lost.  The missing tower railing is smoothed out, but still missing- by the time FXAA post-processes the image, the railing is already gone.

In this side view of the fence, we can see aliasing as the fence gets farther away (and each hole in the fence is smaller due to perspective).  Anisotropic filtering will not fix this because the aliasing is coming from the per-pixel alpha cutout, not from reading the texture itself.

Again, 4x SSAA gives us double the resolution for alpha operations, so the fence looks better over a longer distance.

With FXAA the aliasing is less ugly (as FXAA smooths the errors) but it cannot reconstruct the lost resolution.

If 4x SSAA makes better alpha, why not use it all the time ?  The answer is expense: 4x SAA uses 4x the VRAM for the deferred rendering buffers, and burns 4x the fill rate on all geometry and all lighting!  4x SSAA is one of the only settings that will seriously destroy framerate even for a high-end GPU.  FXAA, by comparison, only costs a few fps on a decent graphics card.

* In the screenshots, the setting that turns on FXAA is labeled “fake aa”.  This is not meant to be an insult to FXAA, which is really an astoundingly nice piece of shader code.  That control wires up my own home-rolled anti-aliasing algorithm post-processing which works very badly and looks ugly – I called it “fake” because I was just faking it.  I then installed FXAA into the same setting but never re-labeled it.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

46 comments on “FXAA: Your New Friend”

  1. As long as the best solution is made available for release for us user. Good to know the differences , but no one wants junk jagged textures. Dx11 high end cards should suffice.

    – * Are the ground textures changing at all in looks in v-10 from v-9, the grass covered hills and grass around KSEA look no different?

  2. What is interesting is that both FXAA and SSAA seem to be smoothing filters – in essence. You can see that in the runway and taxiway lights in the KSEA shots. While the jaggies go away, the lights soften and merge at the same time. Not necessarily a bad effect. A trade-off between jaggy background and sharp foreground.

  3. Nice tree on the second set of pictures.
    And is it possible (while very expensive I think) to use SSAA + FXAA?

    1. They don’t work well together in our implementation because the FXAA apply is after the SSAA resolve – so the jaggies are partly gone by the time FXAA sees them, and that tricks FXAA into not anti-aliasing strongly. If the pipeline were reversed they’d work better, but the FXAA would cost a lot more.

  5. What’s the effect of FXAA on rain? Speaking of which – on XP9, is rain processed by the GPU or CPU? Any changes planned for it in XP10?

    PS: thanks for curing my anxiety 😉

    1. FXAA doesn’t hurt the rain effect – the threshold for softening is pretty high up on FXAA, so it tends to not damage image quality.

      Austin recoded rain for v10. In v9, it’s a texture wrapped around the camera, in v10 it’s physical 3-d drops – the drops on the 2-d panel are also on a modernized, streamlined code path.

      1. Very cool info on new rain, sounds like it will be very nice looking and won’t kill fps, as other previous posts have mentioned v-10 will run better.

      2. Very cool Ben. Does the move to 3D drops allow for effects like light diffusion under rain to feel more realistic?

        1. No. (The lighting model can’t “probe” the 3-d rain drops at reasonable framerates. We may someday be able to program some kind of diffusion effect directly into the light model.)

  6. Ben,
    As Chris asked this, are there going to be updates to the Mesh & Textures in V10?

    Also will SLI be a usable factor?

    Thanks
    ed

    1. Yes, the mesh and textures will be updated. We took better data sources for the mesh and have been incrementally reworking the textures, and we have new shaders for various terrain effects. We also have completely new, higher res land class data. I think this was covered in past blog posts.

      SLI: probably still not useful. We’ve commented on SLI repeatedly in the past: we don’t have SLI machines, so we don’t know if it’ll help, and it’s almost always better to get one fast GPU than two slower ones. If I get more multi-GPU info I’ll post it.

  7. The grass and mountains and such look fine actually, no real issues there if un changed. The problem ( which im 99% sure is being solved) is having city repeated textures and images on the ground of 5000 baseball fields and walmarts.

  8. So no more repeated baseball fields and city texure overlay images correct? walmart and ikeas all over, no more? sure hope so, pretty sure this won’t happen based on previous posts though 🙂

    Also, any idea how much faster or better v-10 will run than v-9 on the same system or better sytem. ie frame rate

  10. It’s so sad to have to say this but if we can’t keep the comments related to the post, we’re going to have to start filtering comments out which is a waste of everyone’s time. This topic is FXAA. Let’s keep the questions relevant please.

  11. So I guess my next graphics card must have FXAA to keep ahead of the game – that’s important information. Plus one gig of VRAM. We all love hi res’ and AA. In fact, I’m pretty pleased with Vs 9 except when a loaded plane meets loaded scenery under loaded weather.

    1. No – not true!

      FXAA is _not_ a built-in hardware feature. It is a pixel shader that a guy at NVidia wrote that we can use. So you just need a DirectX10 or better video card, something you might already have. (If you do not have a DX10-class card or better, you can’t run HDR, and you don’t have deferred rendering, so all is moot.)

      But do get a lot of VRAM! We have a lot more art assets, and third parties are using a lot too!

        1. I cannot possibly answer that question.
          1. We don’t know. The sim isn’t done yet. Perf will change as we continue to develop.
          2. The hw describes is totally vague. It depends on the CPU, memory, bus, etc. Even among 1 GB DX11 cards, you have two vendors and a wide variety of cards with different numbers of shaders and clock speeds. It’s like asking “how fast will a car drive”? A ferrari and a civic have different top speeds.
          3. “How well” is completely subjective. It depends on what rendering settings you like, how much you care about fps, and how much you care about visual quality.
          4. Even if you were to perfectly describe your computer system, we still wouldn’t know. We can’t build a matching system in your lab to perf test it.

          You’re going to have to wait for the product to ship to get an answer to this. Once the product ships, people will be able to post their system specs, ren settings, and framerates with screenshots, and then you will be able to decide for yourself.

  12. simple question- new world textures yes or no- walmarts and baseball fields everywhere yes or no.

    Thank you, I would not have to ask numerous times , nor would other users with their questions if LR had good customer service via here and fb. info@xplane.com is pretty good. But here we get A. no reply, B- delayed reply, C- short and sarcastic replies negating the inquiries of fans.* not just me. Not going so well for customer service Nor would we have to if the stream of detailed exact features and shots came out routinely.

    in that case, re phrased- will FXAA help make the sim run better, and run like anti aliasing settings currently in place to avoid crappy jagged textures.

    2. Hi Chris,

      First: this is not customer service. This is the developer blog. This is where Chris and I take a break from coding X-Plane to share what we are working on before it is released, provide an inside view into how X-Plane works, and try to help third party developers understand where the sim is going.

      If we are not disclosing information, we are not disclosing information. For example, we have not discussed X-Plane 10’s visibility. I am working on that code now and I will post about it when I am completely sure that what I am posting is actually correct. No amount of repeated questioning is going to change my decision as to whether or not a topic is ready for discussion. X-Plane 10 is not done yet, it has not shipped yet, and we are not necessarily prepared to discuss every aspect of it before it ships. Even if you do not understand why, for marketing reasons, a company would not disclose pre-release information pre-ship, you need to respect that boundary when you are commenting on this blog. If you are frustrated at our silence, other forums exist to vent that frustration.

      Second: screenshots. I am not going to delay X-Plane 10’s release by stopping development to create additional marketing materials. Someone else in the company may do that, but my mission is clear: ship X-Plane 10 ASAP. The screenshots posted here are ones I have available from my day to day work.

      So let me make this absolutely clear: I have had enough. If you post repeated questions, I am going to reject your comments. If you ask questions that have already been answered, I am going to reject your comments. And if you go on a rant about how you aren’t getting good customer service because we are not disclosing pre-release information to you, I am most definitely going to reject your comments.

      Finally, re: FXAA: FXAA makes the sim run slightly slower than no FXAA, but with less jaggies. You can see this from the framerates and screenshots in the post.

      1. Ben,

        FXAA- alright, little speed for some quality, makes sense. We already have rendering options now to vary this level of realism , not too much of an issue

        screenshots- more would be nice, as always, but yes i’d rather see v10 sooner , so alright ( even if i don’t get what is time consuming about snapping an image and posting, like the shots on this forum,)

        repeated questions, I’ll scale back on those, v-10 release more important. find out more info as the time nears.

        goal- v-10 to be much better, run faster than v9, better optimized ( as I have read), and asap (kind of has to be by or on Christmas this year) like the announcement said, but sooner is better 🙂

  13. There are several other types of AA technics, Multisampling, Adaptive Multisampling and so on (some might be a child of marketing, I assume)…
    But, how do they relate to the problem X-Plane has with FSAA?

    I for myself don’t like FXAA and I don’t think it is a substitute for FSAA. Antialiasing is not about softening parts of an image, its much more. And I’d like to see a video of FXAA in action, I assume it will behave even worse in critical situations (fine details with high contrast moving slowly).

    FSAA 4x is awesome, the best tradeof between performance and image quality IMHO. I hope SSAA will be useable with an descent GPU at least…

    Thank you very much and sorry for my english.

    1. Fortunately you don’t need me to answer these things: the various types of FSAA and the problems with deferred rendering are universal to 3-d graphics, not specific to X-Plane. So you can find plenty of articles on the web about MLAA, FSAA, FXAA, etc. etc. including screenshots and performance info.

      Generally: deferred rendering (in X-Plane and other titles) is incompatible with all hw FSAA that is based on multiple samples at rasterization time. This includes Adaptive MSAA, CSAA, SSAA, etc.

      You are correct that FXAA is not a substitute for a higher sampling rate – the nyquist frequency of the screen does not change. Generally, SSAA will be usable if you have a good GPU and aren’t also pushing the screen res. If you want to run at 2560 x 1440 you’ll have to use FXAA. That’s just how it goes.

      1. Thank you very much for your answer.

        Generally: deferred rendering […] is incompatible with all hw FSAA that is based on multiple samples at rasterization time. This includes Adaptive MSAA, CSAA, SSAA, etc.

        OMG… Well, when there is such a substantial change ongoing, I hope AMD/NVidia will bring up a new and better solution soon.

  14. What is the difference between FXAA and FXAA II, and would you go straight to FXAA II, If a new version came out (say FXAA III) is it hard wired into the software or can it be updated in a Xplane .upgrade, please excuse the ignorance here Ben but would you adjust the amount of impact of the shading (CPU/Framerate) does by adjusting the anti-aliasing in the rendering dropdown as we do now or is it a different system.

    1. Taking updates to the shader should be relatively easy. I am not sure if we are using rev I or II of the shader – Timothy’s blog covers the improvements in each algorithm in a lot of detail.

      FXAA does have some quality vs fps trade-off options but we haven’t wired them up to the UI, since the shader is very light-weight overall (that is, we haven’t seen a need to simplify on a machine capable of running HDR mode in the first place).

  15. So if I read it right, this feature can be used by ATI or NVIDIA cards that support DX10? Sorry for sounding repetitive … just wanted to be sure it is vendor-agnostic.

  16. Hmm, you can tell that FXAA doesn’t have much to work with. If you can recognize the stairsteps after FXAA, I bet you’ll get AA-less-like shimmering in motion. Oh well. 🙁

    It seems newer cards/specs can run shaders at the sample level. That would allow your standard FSAA to work, with the benefits of more samples to work with, and better sample locations (unlike homebrew SSAA). Will we be seeing that in some future version of X-Plane? And, hopefully in Apple’s some vendor’s drivers.

    1. Right – FXAA can’t address low frequency temporal sampling issues.

      And yes, the newer cards do have sub-sample access to frame buffers; I am not sure how this will produce any better fill rate than SSAA though; while you might get better sample positions, you’re still going to have to write to a huge buffer (X times larger than the base g-buffer) to get correct per-pixel normal info (the MSAA will save shader ops on the first pass, but not memory bandwidth or fill rate) and then (more importantly) the lighting pass will have to run lighting calcs on pretty much every sample.

      (At least, I don’t see how you “recover” the number of discrete layers rasterized into a pixel from the samples without checking _every_ sample on the lighting pass.)

      I don’t know if you’ll see it in x-plane. I can’t predict that – we’re going to always try to keep adopting better rendering tech but maybe by the time the support for multisample gbuffers are wide-spread, something better comes along…who knows!

      1. Well, I’m not sure what hardware actually does, but MSAA does offer a lot of optimization opportunities. First is obviously reduced fragment shading. But a direct consequence is that most pixels in the framebuffer (anything that isn’t a polygon edge) will contain the same value across all samples, allowing easy and cheap compression. When you subsequently do post-processing, you can take advantage of the compression info by only shading per-pixel where the samples are actually different.

        Of course it needs some minimum feature size to work effectively (presumably shader-core-SIMD-sized blocks of pixels should lie within a single polygon, or possibly be lucky enough to only contain ‘hard’ edges, to enable the optimization), but it should recover some FPS, more so at those expensive higher resolutions. Just don’t ask for individual samples of the depth buffer, I guess.

        As to how you would access the hardware to do this, I don’t know. This is just the impression skimming through one of the newer GLSL versions (where you could mark individual variables as per-sample) a while ago left on me. It seems to specifically allow this sort of optimization.

        1. Right – a typical modern forward-rendering hw MSAA will multi-sample coverage or depth and blend one shaded sample based on that coverage – the blending can be out of order – and as a result you get nice AA rasterization without increased shader cost.

          But we have a deferred renderer…so this yields two problems:
          1. In order to reconstruct the final colors, we need to blend sub-samples into a full pixel _after_ we apply lighting, which means we need the full g-buffer state per _sample_ ahead of time. In other words, if the hw computes coverage in pass 1 and mixes down a final per-pixel g-buffer state, that g buffer is the average of all contributing samples and thus totally wrong.

          So at a minimum, coverage or depth-only style multi-sampling is not adequate; even if the shader is called once per pixel, the results must be stored per sample.

          2. How do we then save any work? I suppose the answer is: if the lighting calcs are expensive, we would loop through our multi-samples and identify and weight the existing fixed number of unique g-buffer tuples. That is, in some cases we might early-exit because all g-buffer tuples are the same, or we’d even get to run the lighting calcs only for as many cases as we have.

          (It might be quicker to only optimize the coherent case…hard to say without real data.) For fine geometry, where polygon edges are cutting through a lot of pixels (especially with tessellation) we might not hit the optimal case very much.

  17. Wait, I think you have some things mixed up about multisampling, Ben. With multisampling, the color samples are stored individually alongside depth and stencil in the multisample buffer. The ‘normal’ color buffer that now contains the downsampled image is separate, and doesn’t destroy the samples. When the spec speaks of one color value and n depth samples per fragment, it speaks of fragments as in the fragment shader output before it is written/blended to the framebuffer, not the pixels stored in the framebuffer. The framebuffer still contains all the samples. It’s really just a matter of accessing the information that’s already there.

    I have actually seen it with my own eyes once when I confused the driver with a particular glReadPixels path. It ended up transferring the color values straight out of the multisample buffer, giving me a double-size image full of 2×2 blocks and jittery geometry edges (due to the rotated grid). I happened to experiment from within an X-Plane plugin to have some free content to work with, when I ran into that. 🙂

    —-

    Note I presume the hardware will recognize that a block doesn’t contain geometry edges, so your post-process shader is mostly agnostic to the optimization. Just specify that you’d like to work on individual samples, and if the hardware then sees that the samples in each pixel in a block are the same, it can optimize by only running once per pixel. Again, I’m not sure how it actually works, but it seems like a great solution that’s hard to miss.

    Very fine geometry kills either way. It’ll reduce fragment core utilization, add additional vertices to process, etc. I don’t think the hit of having to post-process every sample will be disproportional, seeing what came before it.

    1. If the GPU is using something like CSAA, the number of coverage samples may be larger than the number of color samples. I suppose this would be exposed via the smaller color table. (When I last read the CSAA notes I mistakenly thought they had separated the number of color and depth samples; this is clearly not the case.)

      Whether this matters is a question of whether the deferred renderer is bottlenecked on raster ops/internal bandwidth or shader ops. At this point I don’t know which one we’re using more of, relative to card capacity.

      1. Ah, CSAA – Completely Secret AA. As I understand it it should ideally be comparable to my ‘ideal’ MSAA description. CSAA may mess up occasionally, but the result should be comparable regardless of the type of rendering. Performance should be comparable to MSAA (yeah, the deferred work would probably be done pretty much directly on the color values). But then, being primarily a Mac user, I haven’t even seen CSAA in action yet.

        I should read some of the newer specs to get a clearer image myself, at least of what the API allows…

        1. Well, for what it’s worth, CSAA has 4 real color samples, so probably the API would just claim “yeah you have 4 color samples” and off we go…I think there’s no way for a deferred implementation to get access to the coverage information when it needs it, but such is life.

  18. Thanks for another informative and interesting blog entry. Much appreciated.

    Now I understand a bit about X-Plane 10 anti-aliasing, it begs the question, how does it work in X-Plane 9? To be honest, I could never see the effect of changing the rendering setting, anti-alias level.

Comments are closed.