Firestorm: Anti Aliasing

[Raven Huntsman]

Does anyone know of a way to get better Anti Aliasing in Firestorm? Something comparable to Black Dragon? (I cant stand BD for general use as it does everything I do a lot like building just a little bit too awkwardly for my liking). I've tried forcing Anti Aliasing improvements through my NVIDIA Control Panel but this doesn't work great in Firestorm as it gets applied to all of the UI + Text causing blurriness. Wondering if anyone knows any ways to improve graphic fidelity with firestorm in tow.

[bigmoe Whitfield]

@NiranV Dean  

[Rachel1206]

I got a high end GeForce RTX and a fast new ICore7, normally at home I have 120+ FPS without blurry text/UI, I use the following settings:

 

 

FS User Interface Font

I use the Roboto font in FS without any font size adjustment, other font types I get blurry UI. Check Preferences->User Interface->Font

 

Edited January 24, 2022 by Rachel1206

[Henri Beauchamp]

Using FXAA or MSAA (AKA pseudo 16x AA) will cause blurry 3D and UI.

I do not recommend using any pseudo AA methods (FXAA, MSAA, CSAA, EQAA, etc, etc).

Only SSAA (super-sampling AA, AKA FSAA = full screen AA) properly works and avoids any blur. The rest are approximations used to try and alleviate the load on the GPU while approaching the ”true thing”, i.e. SSAA.

4x SSAA gives by far the best results (keeping the image sharp, not affecting the least the UI fonts, and properly smoothing out the jagged edges), while not costing you much in performances (modern GPUs can do it at almost no performance loss, especially in SL where modern GPUs load is rather modest).

8x SSAA does not give better results (I personally find them even slightly worst, actually) but would cost you some FPS.

”16x AA” is not SSAA (it would load the GPU too much) and actually triggers FXAA or MSAA (depending on the GPU). It is far worst than 4x AA because of the blur it introduces (especially on the UI fonts, but also in the 3D scene).

 

For the viewer do not set the AA mode from the driver control panel, but instead choose ”let the application decide” (or whatever it is called by your driver), then set the AA mode from the viewer graphics preferences, and avoid the 16x (pseudo) AA mode. Remember to restart the viewer after changing the AA setting (it might not tell you to do it, but usually won't properly switch to the right AA mode until restart).

Edited January 25, 2022 by Henri Beauchamp

[Rachel1206]

1920x1080 cut from original 2K screen grab. Firestorm with graphics set to ultra and the above earlier shown settings.

Notice, how good text is shown in chat (click image to see original size). I included HUD examples to show how clear text are shown on those.

FXAA (fast approximate anti-aliasing) was developed by Nvidia and is a post processing none-3D technique done on whole displayed image with minimal impact on performance. It cannot be used alone, normal 3D spatial anti-aliasing is needed.

 

Edited January 25, 2022 by Rachel1206
Spelling

[NiranV Dean]

On 1/24/2022 at 6:05 PM, Raven Huntsman said:

Does anyone know of a way to get better Anti Aliasing in Firestorm? Something comparable to Black Dragon? (I cant stand BD for general use as it does everything I do a lot like building just a little bit too awkwardly for my liking). I've tried forcing Anti Aliasing improvements through my NVIDIA Control Panel but this doesn't work great in Firestorm as it gets applied to all of the UI + Text causing blurriness. Wondering if anyone knows any ways to improve graphic fidelity with firestorm in tow.

23 hours ago, bigmoe Whitfield said:

@NiranV Dean  

Firestorm as far as i know uses FXAA (when setting AA to 2x) whereas it switches to the oldschool MSAA that we had years ago when going above that. The difference between forcing it through the NVidia Control Panel and doing it in the Viewer is that as you already noticed, forcing it will apply it to the UI as well but will most likely result in better performance due to a better implementation, the in-Viewer implementation however does not include the UI and should give you similar results.

BD (like the official Viewer) unlike FS does NOT have any other AA mode, people falsely assume that setting AA to anything but 2x makes a difference, it does NOT. All Viewers that do not implement an extra AA (as far as I know almost all of them, except FS, Alchemy and possibly Cool VL Viewer) only ever use the 2x setting which is FXAA. BD only uses FXAA and nothing else, the only reason I see why BD's AA could be slightly better is because I modified the FXAA preset to force the High Quality "39" preset and made some minor adjustments to the edge detection settings, they might or might not be better at times.

Coming back to your question however how to get a "better" AA like BD apparently has, you could take the FXAA shader from BD and copy it into FS, have it replace FS's FXAA shader, this would give you the same FXAA preset and settings BD uses but you'd have to repeat this every time FS updates. The shader file can be found in:

Black Dragon\app_settings\shaders\class1\deferred\fxaaF.glsl

Edited January 25, 2022 by NiranV Dean

[Henri Beauchamp]

1 hour ago, NiranV Dean said:

Firestorm as far as i know uses FXAA (when setting AA to 2x) whereas it switches to the oldschool MSAA that we had years ago when going above that. The difference between forcing it through the NVidia Control Panel and doing it in the Viewer is that as you already noticed, forcing it will apply it to the UI as well but will most likely result in better performance due to a better implementation, the in-Viewer implementation however does not include the UI and should give you similar results.

BD (like the official Viewer) unlike FS does NOT have any other AA mode, people falsely assume that setting AA to anything but 2x makes a difference, it does NOT. All Viewers that do not implement an extra AA (as far as I know almost all of them, except FS, Alchemy and possibly Cool VL Viewer) only ever use the 2x setting which is FXAA. BD only uses FXAA and nothing else, the only reason I see why BD's AA could be slightly better is because I modified the FXAA preset to force the High Quality ”39” preset and made some minor adjustments to the edge detection settings, they might or might not be better at times.

Coming back to your question however how to get a ”better” AA like BD apparently has, you could take the FXAA shader from BD and copy it into FS, have it replace FS's FXAA shader, this would give you the same FXAA preset and settings BD uses but you'd have to repeat this every time FS updates. The shader file can be found in:

Black Dragon\app_settings\shaders\class1\deferred\fxaaF.glsl

I am afraid you are mistaken with FSAA (AKA SSAA) modes and the post-processing FXAA shader of the viewer (which is only used when deferred rendering, AKA ALM is enabled). Your confusion might stem to the fact that in their (not so) great wisdom, LL's coders are using the same AA setting (RenderFSAASamples) to govern both FSAA and the enabling of the fxaa.glsl shader (enabled in ALM when RenderFSAASamples > 1).

The viewers (AFAIK, all of them) use the FSAA modes for 2x to 16x (the ”fsaa” samples parameter is passed at the OpenGL context creation, and this is an OpenGL feature dealt with at the GPU/driver level without any need for a shader). However the 16x mode is in fact faked by most (all ?) drivers (for NVIDIA it triggers full screen MSAA, which causes the blurry fonts). Unless your GPU/driver does not support 4x and 8x true FSAA modes (in which case it might switch to MSAA), 2x, 4x and 8x modes do give different results (but it might not appear they do when ALM is on, because of the FXAA post-processing shader).

 

Again. For the viewer, use 4x AA mode (it's by far the best and will not tax your GPU): you can observe its effect with ALM turned off.

It might be a good idea to allow disabling the FXAA shader entirely (I really don't like the blur seen in ALM mode)... I'll try that for my viewer...

Edited January 25, 2022 by Henri Beauchamp

[NiranV Dean]

24 minutes ago, Henri Beauchamp said:

I am afraid you are mistaken with FSAA (AKA SSAA) modes and the post-processing FXAA shader of the viewer (which is only used when deferred rendering, AKA ALM is enabled). Your confusion might stem to the fact that in their (not so) great wisdom, LL's coders are using the same AA setting (RenderFSAASamples) to govern both FSAA and the enabling of the fxaa.glsl shader (enabled in ALM when RenderFSAASamples > 1).

The viewers (AFAIK, all of them) use the FSAA modes for 2x to 16x (the ”fsaa” samples parameter is passed at the OpenGL context creation, and this is an OpenGL feature dealt with at the GPU/driver level without any need for a shader). However the 16x mode is in fact faked by most (all ?) drivers (for NVIDIA it triggers full screen MSAA, which causes the blurry fonts). Unless your GPU/driver does not support 4x and 8x true FSAA modes (in which case it might switch to MSAA), 2x, 4x and 8x modes do give different results (but it might not appear they do when ALM is on, because of the FXAA post-processing shader).

 

Again. For the viewer, use 4x AA mode (it's by far the best and will not tax your GPU): you can observe its effect with ALM turned off.

It might be a good idea to allow disabling the FXAA shader entirely (I really don't like the blur seen in ALM mode)... I'll try that for my viewer...

No, i'm basing it on the fact that 4/8/16x makes no difference and AA doesnt even work without Deferred at all in both my Viewer and the Official one, also checking the code there is no indication of FSAA samples option being used anywhere else other than inside Deferred. Like I said anything else is an extra implementation. Your Viewer came from V1 so i'd assume you kept MSAA which was removed around 2.7. If 4/8/16 actually made a difference i'd have kept these options.

Edited January 25, 2022 by NiranV Dean

[Henri Beauchamp]

30 minutes ago, NiranV Dean said:

No, i'm basing it on the fact that 4/8/16x makes no difference and AA doesnt even work without Deferred at all in both my Viewer and the Official one, also checking the code there is no indication of FSAA samples option being used anywhere else other than inside Deferred. Like I said anything else is an extra implementation. Your Viewer came from V1 so i'd assume you kept MSAA which was removed around 2.7. If 4/8/16 actually made a difference i'd have kept these options.

There is NO MSAA support in my viewer. Only pure FSAA/SSAA. Just like in LL's official viewer (mind you, my code is not just v1 code: I kept backporting v2+ code !).

Relevant code is in llwindow(sdl/win32/macosx).cpp. Just look for the mFSAASamples member variable usage (and see how it is passed at the OpenGL window/context creation).

And I do see a difference between 2x/4x/8x with LL's viewer... Of course, if you override AA setting system-wide, at the driver level, you will not see anything.

Edited January 25, 2022 by Henri Beauchamp

[NiranV Dean]

17 minutes ago, Henri Beauchamp said:

There is NO MSAA support in my viewer. Only pure FSAA/SSAA. Just like in LL's official viewer (mind you, my code is not just v1 code: I kept backporting v2+ code !).

Relevant code is in llwindow(sdl/32/macosx).cpp. Just look for the mFSAASamples member variable usage (and see how it is passed at the OpenGL window/context creation).

And I do see a difference between 2x/4x/8x with LL's viewer...

Weird, i don't see a difference... 

and without deferred AA doesn't work at all:

Make sure you dont have Nvidia extending the Viewer capabilities in your drivers.

Edited January 25, 2022 by NiranV Dean

[Henri Beauchamp]

Well, here is what I get. To be sure the upload to a third party site won't degrade the snapshots quality, I uploaded them to my site:

No anti-aliasing

2x FSAA

4x FSAA

8x FSAA

16x MSAA (the viewer asks for 16x FSAA, but the driver switches to MSAA)

All snapshots taken with ALM off (so that LL's FXAA shader does not interfere). Looking at the edges of the primitives, the differences are obvious !

Notice how 4x is indeed the best (jagged edges start to reappear at 8x: my theory is that the super-sampling is so high at 8x, that it becomes much smaller than a single pixel and starts to differentiate the jagging as if they were different edges, not smoothing them out by averaging their colours properly as a result).

At 16x, the blur appears, quite visible also on the background texture (while there is no jagged edge to smooth out there): this is the result of the MSAA algorithm which is just a kind of pondered blurring. Also (not seen in those screen shots), with MSAA the fonts and UI get blurry as well (and the fonts are distorted when compared to their normal aspect).

Edited January 26, 2022 by Henri Beauchamp

[NiranV Dean]

42 minutes ago, Henri Beauchamp said:

Well, here is what I get. To be sure the upload to a third party site won't degrade the snapshots quality, I uploaded them to my site:

No anti-aliasing

2x FSAA

4x FSAA

8x FSAA

16x MSAA (the viewer asks for 16x FSAA, but the driver switches to MSAA)

All snapshots taken with ALM off (so that LL's FXAA shader does not interfere). Looking at the edges of the primitives, the differences are obvious !

Notice how 4x is indeed the best (jagged edges start to reappear at 8x: my theory is that the super-sampling is so high at 8x, that it becomes much smaller than a single pixel and starts to differentiate the jagging as if they were different edges, not smoothing them out by averaging their colours properly as a result).

At 16x, the blur appears, quite visible also on the background texture (while there is no jagged edge to smooth out there): this is the result of the MSAA algorithm which is just a kind of pondered blurring. Also (not seen in those screen shots), with MSAA the fonts and UI get blurry as well (and the fonts are distorted when compared to their normal aspect).

Weird. It is obvious that this isn't FXAA (otherwise the fine floor detail would get blurred) but the real question is why does it even work for you and why does it impact the UI (which it only should if its forced via drivers). Did you check and make sure you have no graphics driver profile for the SL Viewer and also not globally set to "extend the application" for AA solutions?

EDIT: Also oof, i just noticed that i posted (and apparently saved) the 2x snapshot twice... i had to do it via snipped tool and save it as external image because for some reason simply paste (CTRL + V) the image in clipboard is not working here anymore... lemme make new ones, i'll just take full snapshots this time.

Disabled

2xFSAA

4xFSAA

8xFSAA

16xFSAA

As you can see there is zero difference. Also the ground texture becomes more blurred starting at 2x and stays the same way (due to FXAA being used)

Edited January 26, 2022 by NiranV Dean

[Henri Beauchamp]

8 hours ago, NiranV Dean said:

Did you check and make sure you have no graphics driver profile for the SL Viewer and also not globally set to ”extend the application” for AA solutions?

I never use ”application profiles”. I never impose AA settings from the driver control panel/settings. I get the same result under Linux (where the driver configuration is much simpler, with exported environment variables preferred to configure it from the wrapper scripts of the applications).

I always got the same results with regards to AA in 15+ years of SLing, always used FSAA/SSAA, and always choose 4x, since it always has been the best option, by far.

Quote

As you can see there is zero difference. Also the ground texture becomes more blurred starting at 2x and stays the same way (due to FXAA being used)

This could be the driver imposing a different, pseudo (i.e. not super-sampling) AA mode on you... Double (triple, quadruple) check your driver settings.

Or... Your GPU cannot do any more true AA (this might be what the future got in stock for us, with both AMD and NVIDIA pushing their new fancy AA methods down our throats, sacrificing quality for (hopes of) more speed)...

Edited January 26, 2022 by Henri Beauchamp

[NiranV Dean]

13 hours ago, Henri Beauchamp said:

I never use ”application profiles”. I never impose AA settings from the driver control panel/settings. I get the same result under Linux (where the driver configuration is much simpler, with exported environment variables preferred to configure it from the wrapper scripts of the applications).

I always got the same results with regards to AA in 15+ years of SLing, always used FSAA/SSAA, and always choose 4x, since it always has been the best option, by far.

This could be the driver imposing a different, pseudo (i.e. not super-sampling) AA mode on you... Double (triple, quadruple) check your driver settings.

Or... Your GPU cannot do any more true AA (this might be what the future got in stock for us, with both AMD and NVIDIA pushing their new fancy AA methods down our throats, sacrificing quality for (hopes of) more speed)...

Both global and application level don't have a profile for the Viewer (I know I had one specifically for BD back on Windows 7 a couple times to try a couple things after which i removed it because it kept reducing the framerate massively) but even if I still had one it wouldn't affect the official Viewer but I checked again just to make sure.

Any AA above 2x has stopped working for me around Viewer 2.7 (which was around the time FXAA was introduced and replaced MSAA). As far as i can tell from the commits MSAA support was disabled completely: 

https://bitbucket.org/lindenlab/viewer/commits/2dd8ce53e4e0d14f2bc20796eb6bdf1ef12a65df

https://bitbucket.org/lindenlab/viewer/commits/7ee10ae1def26708fa44c25355982aa56195d5f9

It should not be working, the Viewer has no other AA implementation either.

I doubt that my GPU can't do true AA anymore, both old and new games with many different AA implementations (from original MSAA to FXAA, SMAA, TXAA/TAA, SSAA, CSAA all the way up to 32x) work fine, the only thing I can't get to work is driver-level SSAA in SL, works fine everywhere else. I'm using a GTX 1060 so nothing too fancy and far from top of the line, that's around medium range GPU. NVidia's 32xCSAA was really really nice and incredibly fast (I've only ever seen a single game make use of it, sadly it's no longer supported and has been dropped down to 16xCSAA).

[Henri Beauchamp]

35 minutes ago, NiranV Dean said:

Any AA above 2x has stopped working for me around Viewer 2.7 (which was around the time FXAA was introduced and replaced MSAA). As far as i can tell from the commits MSAA support was disabled completely: 

https://bitbucket.org/lindenlab/viewer/commits/2dd8ce53e4e0d14f2bc20796eb6bdf1ef12a65df

https://bitbucket.org/lindenlab/viewer/commits/7ee10ae1def26708fa44c25355982aa56195d5f9

It should not be working, the Viewer has no other AA implementation either.

Again, you are confusing FSAA (asked via the OpenGL window/context creation, dealt with in llwindow implementation), with the FXAA shader used exclusively in ALM mode, in the render pipeline. The two commits you quote have changed nothing to the Ope,GL context/window creation, where the FSAA mode is still set.

[NiranV Dean]

58 minutes ago, Henri Beauchamp said:

Again, you are confusing FSAA (asked via the OpenGL window/context creation, dealt with in llwindow implementation), with the FXAA shader used exclusively in ALM mode, in the render pipeline. The two commits you quote have changed nothing to the Ope,GL context/window creation, where the FSAA mode is still set.

Which doesn't have a visible effect on rendering for me however. AA simply does not work beyond 2x (FXAA) for me and doesn't work at all without Deferred. This is how i've been able to tell whether someone runs Deferred or not for years and it was pinpoint accurate, this happens in FS, BD and LL Viewer. I doubt it's my GPU doing this, it wouldn't just be mine either, it would be a wide range of GPU's both NVidia and AMD for a lot of people. It wouldn't be surprising if it was AMD related but NVidia seems like a stretch. I have honestly no more ideas why its not working. Any and all code I can see that prevents it from being used is for Intel or AMD cards (and i mean the multisampling for selection wireframes work too, hence why they are so ass slow)

EDIT

Alright, I finally figured it out. Just took me 10 years.

FSAA and FXAA are not mutually exclusive but cannot be run at the same time.

MSAA and FXAA are mutually completely exclusive. Having MSAA (16x) completely overwrites FXAA and breaks it (as expected for something that is forced driver-side).

That being said, in order to get FSAA to even work you not only have to relog but you also have to have Deferred disabled BEFORE you relog. You CANNOT have Deferred enabled at all, you will have to disable Deferred and turn FSAA samples to the desired value, then relog with Deferred off, Deferred must be off at the time of window creation otherwise it will not work ever. THIS is why I could never get it to work despite relogging many times. I always had Deferred on at window creation and turned it off after.

The reason 16x looks worse than 4x is obviously due to a totally different AA being used, we are talking 4xFSAA compared to what seems like 2xMSAA. 8xFSAA on the other hand seemed to look very slightly better at certain angles but its hardly noticeable and hardly worth twice the amount of sampling.

With this mystery finally being sorted out... settings above 2x is still really totally pointless. Because it A: requires you to have Deferred off at window creation time, which for someone who uses Deferred would be a pain to do and B: doesn't work while Deferred is running which C : is to be expected of any user nowadays (running Deferred that is, at least without shadows). Not even writing a big fat warning on the setting and requiring a restart would solve this solution. You'd have to explicitly tell the user to disable Deferred (and keep it disabled) in order to enjoy a normal AA.

Edited January 27, 2022 by NiranV Dean

[Aishagain]

Bloody Hell.  Reading the above discourse between you two has reduced my mind to jelly and if I had ANY idea of what you were saying at the outset,  I have well and truly lost the plot now.

[Mollymews]

2 hours ago, Aishagain said:

Bloody Hell.  Reading the above discourse between you two has reduced my mind to jelly and if I had ANY idea of what you were saying at the outset,  I have well and truly lost the plot now.

i can't remember now where or when I read it but the story goes that back in 1916 some science reporter for a major newspaper was trying to write an article explaining to the general readership  the recent published Einstein's Theory of Relativity

the reporter was having trouble understanding it all, so spoke to a eminent professor (who's name I can't remember either) at the local university.  The professor says: "I am not surprised to hear you are having trouble. I believe there are only three people in the world who understand this work. And I don't know who the other person is"

is pretty cheeky funny this 😺

Edited January 27, 2022 by Mollymews
typs

[Henri Beauchamp]

11 hours ago, NiranV Dean said:

FSAA and FXAA are not mutually exclusive but cannot be run at the same time.

MSAA and FXAA are mutually completely exclusive. Having MSAA (16x) completely overwrites FXAA and breaks it (as expected for something that is forced driver-side).

This is why I did write in my very first reply to you in this thread , that you had to disable ALM to see SSAA/FSAA at play !!!

Quote

That being said, in order to get FSAA to even work you not only have to relog but you also have to have Deferred disabled BEFORE you relog.

WRONG !

While you do need to restart the viewer after changing the FSAA setting, like I wrote in my first post in this thread, you do not need to touch ALM.

Again: FSAA is requested at the OpenGL window/context creation; it does NOT involve any shader to function, and at creation, the driver got no clue about what are your shaders settings (the shaders are not even yet initialized at this point). Deferred rendering (ALM) is a shader-based rendering method, and its FXAA shader only intervenes when starting to render a 3D scene (not the login screen) with ALM on.

If your or other viewers somehow fail to transmit the FSAA setting, when the viewer is configured to use ALM, to the llwindow call for the window/context creation, then this is a BUG in those viewers code. Mine certainly transmits the FSAA setting unconditionally, and as a result, I can switch off ALM (even after starting the viewer and logging in with ALM on), and enjoy proper FSAA (either 2x, 4x or 8x) after I turn ALM off later in the session. Yes, they cannot work together, but you can switch back and forth between the two without any need to restart the viewer (i.e. FSAA is automatically switched off when the FXAA ALM shader is used, but comes back as soon as you stop using the latter) !

End of the discussion as far as I am concerned (no more time to loose on a non-existent ”issue”).

Edited January 27, 2022 by Henri Beauchamp

[NiranV Dean]

11 hours ago, Henri Beauchamp said:

This is why I did write in my very first reply to you in this thread , that you had to disable ALM to see SSAA/FSAA at play !!!

I know! Obviously FSAA and SSAA don't work when FXAA takes precedence in Deferred but as I wrote I expected it to work regardless of whether Deferred was on/off at startup.

11 hours ago, Henri Beauchamp said:

If your or other viewers somehow fail to transmit the FSAA setting, when the viewer is configured to use ALM, to the llwindow call for the window/context creation, then this is a BUG in those viewers code. Mine certainly transmits the FSAA setting unconditionally, and as a result, I can switch off ALM (even after starting the viewer and logging in with ALM on), and enjoy proper FSAA (either 2x, 4x or 8x) after I turn ALM off later in the session. Yes, they cannot work together, but you can switch back and forth between the two without any need to restart the viewer (i.e. FSAA is automatically switched off when the FXAA ALM shader is used, but comes back as soon as you stop using the latter) !

I would highly assume that it is a bug and like I said the very reason I've never seen FSAA work, otherwise people would have Antialiasing when they turn off Deferred (which almost everyone doesn't) since to have AA in Deferred they need at least 2x set (which doubles as FXAA with Deferred and FSAA without Deferred). I'll have to take a look into this at some point, I remember the RenderFSAASamples debug setting being input into the window creation so I kinda fail to see (in theory) why it wouldn't work. In any way, this means i can add 4x and 8x back as options (given Deferred is disabled) and add a warning to it that it requires a restart.

[Raven Huntsman]

That exchange was super enlightening thanks guys. Though I'm not entirely sure if you guys were sometimes speaking generically (all/most viewers) or referring to your own specific viewers? I know Niran Developed BD at least.

So to draw my own conclusion here; I've been using the typical high end settings in Firestorm up till now (x16 Anti Aliasing/Deferred/No NVIDIA forced enhancements).

And if we're honest, if you want decent/modern graphical fidelity then you're not going to turn off Deferred(ALM). After reading this thread I did try jumping between x4 and x16 and noticed that there is effectively near no difference in the quality.

That being said, this level of quality (in Firestorm) has never been as crisp as I'd like, and it's definitely not as crisp/smooth as what I experience in BlackDragon. I make this statement based on what I see when in both viewers during use and also from the quality of edges of avatars in images when taking high res (4k) shots in both FS and BD.

 

So for anyone reading this in the future looking for similar reasons;

Conclusion: There isn't much we can do if we rely on existing viewer settings to get better fidelity out of SL. 

A note: I jump between HD/QHD/4K monitors (I've got like 4 monitors due to covid), the higher resolution monitors definitely improve edge fidelity by a fair amount (so many more pixelllllsss). Worth mentioning I thought as better monitor hardware does improve quality if you were unsure.

What worked for me in this case (I tried a couple of things in different combinations until I was happy with the result):

• I replaced the default Firestorm FXAA shader with Niran's BlackDragon FXAA shader as mentioned in his post. (Unclear if this helps in Firestorm as I can't tell if it's using FXAA with hardware AA on).
• I then forced AA via the NVIDIA Control Panel with settings near identical to the ones detailed by @Rachel1206 (Thank you)
• I also changed my Firestorm font to roboto.
• And I set my viewer Anti Aliasing setting to x16. This definitely made a difference compared to x4 with NVIDIA forced AA, might be the result of the breakage or overlap that was mentioned or combination of MSAA.

I suspect the main tweaks here that are helping are the texture related settings in the NVIDIA Control Panel + the font change which allow me to benefit from forced AA without a blurry font. All of these changes result in an edge fidelity comparable to what I get in BlackDragon. Aka, no jaggies at all. And with a 30 series card, I'm not worried about GPU load either but this may not be a solution for everyone.

Thank you

 

Edited February 3, 2022 by Raven Huntsman