Author Topic: Practical FXAA  (Read 67 times)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1280
Practical FXAA
« on: June 11, 2019, 05:26:16 pm »
I'll be damned!!! I got FXAA working!!!

(!!! No visible trace of extra GPU usage !!!)

8) 8) 8) 8)
« Last Edit: June 11, 2019, 10:46:40 pm by Michael Lobko-Lobanovsky »
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1419
    • zapsolution
Re: Practical FXAA
« Reply #1 on: June 11, 2019, 07:19:42 pm »
Thumb up my friend!
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1280
Re: Practical FXAA
« Reply #2 on: June 11, 2019, 07:26:50 pm »
Thank you, my friend!

I need time to tweak its parameters and incorporate it into the menu.

It looks a little poorer than the 32x MSAA to which we have already grown accustomed to but it comes at absolutely no cost for animated model+animated background combinations! And we can still keep MSAA switchable for crucial high quality renders, after all. :)
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1280
Re: Practical FXAA
« Reply #3 on: June 11, 2019, 10:58:31 pm »
In an attempt to push the limits "beyond the horizon" and see how much overhead we really have, I've just run the whole thing at a custom resolution of 2560x1440 pixels on my main monitor.

Of course heavier shaders' usage went up to 100% but more reasonable shaders stayed within acceptable limits.

The screenies I took will give you a better idea of what FXAA is going to look like. As I said, its jaggies aren't perfectly smooth and transparencies look somewhat heavier but overall, the setup seems perfectly usable to me for less demanding animated scenes.

Note that the Serenity model has over 4Mo polies and several animated meshes! :)
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1419
    • zapsolution
Re: Practical FXAA
« Reply #4 on: June 12, 2019, 11:01:13 am »
Yes, antialias looks less smoother to what i am accustomed to.
And for transparency, i shall have to see it on my computer(s) before i could make a reliable comment.

If this FXAA is going to be an extra global #meta (and menu) parameter that is fine to me ;)
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1280
Re: Practical FXAA
« Reply #5 on: June 12, 2019, 03:43:34 pm »
Yes, we're going to have 3 new global #metas regarding AA: #msaa (default), #fxaa, and #csaa (disabled on non-nVidia platforms) probably each followed by one of four parameters off, min, good, or max to denote the respective AA technique and its level for a given model.

Technically, we won't even keep the Use framebuffers toggle in the menu. If the user's OpenGL driver supports FBO, then their main viewport will stay simple (aliased) at all times and Mobj_choosePixelFormat() will be bypassed altogether. All MSAA/FXAA/CSAA adjustments (min=4x, good=8x, max=driver-dependent 16x or 32x -- in terms of MSAA) will be done fast and simple at the moment the FBOs are re-created on window resize. If the driver doesn't support FBOs at all, which is quite unlikely these days, then all AA bells and whistles will be disabled and the main viewport will be created through Mobj_choosePixelFormat() as usual at its maximum MSAA setting possible, and only an ordinary AA on/off option will be accessible through the OpenGL API glDisable/glEnable(GL_MULTISAMPLE). 8)
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1419
    • zapsolution
Re: Practical FXAA
« Reply #6 on: June 12, 2019, 04:00:44 pm »
OK, that sounds good to me!
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1280
Re: Practical FXAA
« Reply #7 on: June 13, 2019, 11:39:43 am »
Well, my here's my progress:

1. I was able to make out what was wrong with Serenity jet transparencies in the hi-res screenie I posted earlier. The cause was a bad choice of d value in the model's cone material. The value was less than that of jet material. But the cones are always farther behind the jets from the observer's point of view and therefore they should be always drawn the first!

To this end, the cone's d should be at least a tad larger than the jet's d. See the topmost screenshot for d adjusted from 0.52 (yours) to 0.7 (mine).

2. To calc the borders that should be anti-aliased, the original FXAA shader uses, evidently for speed reasons, an approximate luma parameter that's tied to the pixel green channel value. I changed that approximation to an exact, classic luma calc that improved the AA quality dramatically -- again practically at no GPU usage cost despite about a dozen additional square roots now being used for each screen pixel.

Default FXAA is now almost as good as 32x MSAA with the only exception of borders whose on-screen inclination angle is very close to a multiple of 45o except near-horizontal and near-vertical ones that are still anti-aliased all right. See the middle screenshot to compare FXAA against MSAA.

3. As I said, despite the substantial extra square root calc in the shader, the overall impact of FXAA on the GPU is close to nil. See the bottommost screenshot to compare CPU/GPU usages at 30FPS for hi-res non-AA and FXAA renders of Serenity against an animated background shader. 8)
______________________________________________

The last but not the least issue I have yet to cope with, is proper mesh texture mipmapping that seems to be at fault when rendered into a non-MSAA FBO...
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1419
    • zapsolution
Re: Practical FXAA
« Reply #8 on: June 13, 2019, 12:51:31 pm »
Thank you for the progress report!
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1280
Re: Practical FXAA
« Reply #9 on: June 13, 2019, 10:31:05 pm »
Patrice,

Technically speaking, the FXAA shader is just another, albeit rather verbose, full-screen post-processing shader like Sepia, Brightness/Contrast and others.

So, my question is:
  • Do we arrange the three anti-aliasing modes (MSAA, CSAA, FXAA) in a mutually exclusive 3-state toggle in their own Anti-aliasing... submenu; or
  • Do we keep FXAA in the ordinary Fancy submenu with the other PP shaders, thus making it effectively applicable on top of MSAA or CSAA if only both of them haven't been explicitly switched off in their own submenu? ;D
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1419
    • zapsolution
Re: Practical FXAA
« Reply #10 on: June 13, 2019, 11:02:40 pm »
Quote
Do we arrange the three anti-aliasing modes (MSAA, CSAA, FXAA) in a mutually exclusive 3-state toggle in their own Anti-aliasing... submenu
Yes, that would be more intuitive.

The menu "View"-->"Render mode control" --> "Design mode"/"Fancy mode" has been superseded by the "Inspect" and "Render" popup menu.
Don't you think that we could get rid of duplication?
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1280
Re: Practical FXAA
« Reply #11 on: June 14, 2019, 07:32:27 am »
I think we shouldn't be using the View menu as our system (right-click) popup at all because it leads to inevitable duplication of the items in the main menu.

Apart from populating the main menu's popups with unique elements grouped logically into File/View/Inspect/Edit/... trees, we should create a dedicated popup menu that will be used exclusively for system RMB double-clicking in the viewport. It should reuse a selection of elements from the main menu in some other general layout that will be most appropriate for use in the full-screen mode.

This will make the View popup lighter and devoid of duplicates with the other popups, and it will make the system popup completely independent of main menu. It can then be made as full of features as we want and I can even move my custom arrangement into my own MLL_DEV.h altogether for conditional compilation.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)