Anisotropic filtering and anti-aliasing

[Antrad 37]

I am annoyed that some bots and some users go around and set these to "false" and delete the user notes when it is written that they can be forced through the GPU panel, and it is left with the default "See the glossary for potential workarounds".

Forcing these can cause texture artifacts in some cases, and forced anti-aliasing doesn't always work, so when I write "can be forced" it means I tested it. I would leave it as hackable, rather than false with default message.

[SirYodaJedi 14]

It's because that's what the editing guide says to do. I agree with you wholeheartedly, and I believe there is another thread with discussion about it. 

[Marioysikax 89]

If my memory serves me correctly, the reason why it's like this is because in huge majority of cases, forcing AF works without any problems, so it would not serve anyone if all games had it either true or hackable. I know people who have set AF to globally forced on and even Microsoft is doing this with Xbox X. 
Because if we only put false on games which have issues with forced AF, there would only be handful from thousands and thousands. 

Also this way, hackable is reserved for per game methods so they are easier to see and find, so that if there's native way of doing things, that's usually preferred over external methods. 

Also if it's been tested to not work, it's far easier to note games were forcing AF externally causes issues. 

[Aemony 142]

@Marioysikax hit the nail on the head. Changing the vast majority of games to "hackable" when resorting to GPU-based overrides essentially dummies the "hackable" state down to not mean a thing. Especially now that GPUs also supports post-processing AAs like FXAA and such that can be performed separately after the game have been rendered without affecting anything in the game itself. It would also open up a question whether using third-party generic tools like ReShade should also simply suffice to set the AA field in particular to "hackable" -- and seeing how ReShade supports all D3D9, D3D10, D3D11, D3D12, and OpenGL games, and you can force FXAA in all of them, wieeee, let's set all to hackable!

Basically, if you want the "hackable" and "false" states to mean nothing on such fields, that's the way to go forward. But if you want actual informative information, you need to exclude generic tools better covered in the glossary page from the "hackable" state, as we're currently doing.

[SirYodaJedi 14]

To further clarify, I am of the persuasion that stuff like MSAA, SGSSAA, etc should be considered hackable, whereas stuff like FXAA, SMAA, etc. should not. Here is the segment of discussion from Discord:

[BONKERS 32]

I have to draw the line that forcing SSAA,MSAA,SGSSAA,TrSSAA should be considered Hackable because these all have to hooked in at the driver level at the appropriate state during rendering. (Hence the need for compatibility bits)

It's not at all like FXAA or SMAA since those are Post Process shaders that are GPU agnostic.  You aren't just taking the final 2D Buffer like the MCable and slapping a filter on it. (Though using FXAA/SMAA with downsampling can be very beneficial https://imgsli.com/OTE5NQ)

Forcing AA at the driver level for Nvidia cards is not a Post Process. And are essentially seen as a driver hack, they require special compatibility  bits to be set (Using a third party program) by most games in order to function correctly. Otherwise you'd be able to do it in DX10,11,newer OGL versions without issue. But you can't because Nvidia didn't bother building in the support into the driver to hook into those kinds of backends. (Because hardware level AA support by developers was decreasing significantly at the turn of the decade, due to moving to deferred rendering where it was claimed often that they couldn't support things like MSAA. Guess what? Nvidia has the capabilities to hook in MSAA support to a ton of DX9 deferred rendering games.)

Often games will require specific things to be setup in addition to compatibility bits for things to work properly. Take FFXIV for example, there are multiple compatibility flags you can use, This image uses a flag that specifically tells the driver to skip the primary flip chain in order to not have SGSSAA process the UI elements. https://imgsli.com/MTAyNDI
But did you also know that you have to use the depreciated DX9 backend to use SGSSAA and did you also know that if you change the in game Gamma setting to *anything* but 50/100 it will completely break forced Anti Aliasing?

Take Crysis 3 for example, it runs on DX11 and you can't "Force" AA. But you can use the in game MSAA,SMAA S2x/4x or TXAA and the driver can hook into those passes  (MSAA derivatives) to "Enhance" the AA instead. This becomes highly dependent on the game engine implementation of those techniques and often is lower quality than forcing AA (It is the only option because there's nothing built into the driver to force AA in DX11) but it still has to be hooked in the game engine by the driver to work.
You can enable MFAA, TrSSAA or SGSSAA on top of the above mentioned. Using SGSSAA causes a bug with grass rendering that depends on which AA you use as a basis. In all cases it cause blades of grass to become very soft and the overall quality is lacking due to the poor MSAA implementation in game. However doing all of this at a higher resolution and downsampling to your desired resolution can mitigate most of the problems or make them less obvious. Aside from FXAA or SMAA on top to clean up edges before resolve (As shown in example above) all of this has to happen at an engine level first. Does that not qualify as "hackable" ?
https://imgsli.com/OTIzMA


It's definitely not as often as simple as using SweetFX or Reshade.(And it gets a bit more complicated if you want to use modern Reshade in addition to forcing AA. As it requires an additional compatibility flag and the forced AA depending on which one will interact and change how the ReShade effects appear. SGSSAA with Reshade Sharpening for example will require much stronger settings than without SGSSAA because SGSSAA replays all shading for all aspects of rendering not just geometry like MSAA and so it will also effectively be anti aliasing the sharpening pass as well. Depending on what effects you are using it can get a little complicated)

In my mind that qualifies as "Hackable" because the game has no support for it, but the driver has to hook into the game engine to make it work. People visit a page for a game because they want specific information for that game. They shouldn't have to dig through other pages to eventually find information on AA for that specific game that they probably have no idea may even exist in the first place. 


Anisotropic Filtering, I feel the same way about because tons of games don't offer it at all, their in-engine version is of lower quality(Like Crysis 2/3 for example. Even at it's highest AF in Crysis 2 is significantly lower quality than the driver verison. Similar to this Just Cause 3 comparison) (http://images.nvidia.com/geforce-com/international/comparisons/just-cause-3/just-cause-3-nvidia-control-panel-anisotropic-filtering-interactive-comparison-001-on-vs-off-rev.html) or their in game option tops out at a lower setting. For games that don't have the option at all, I feel that hackable is appropriate because it's possible that your average user doesn't know they can set it up globally in the driver to override what game engines do.


Maybe a better middle ground instead of "hackable", for any game that there is something possible for, there should be a link in the AA field that just says " See Nvidia Anti Aliasing compatibility "And that would be enough of an indication to the user to search that for information for that specific game. And only put this link on pages for games that there is Nvidia specific things you can do for AA as shown in the spreadsheet.  (Often the best quality performance trade off isn't just forcing AA from the driver it's actually a hybrid solution involving forcing AA+ other methods on top. Or enhancing a game's built in MSAA or MSAA derivative in addition to Downsampling which is OGSSAA. Things like this are listed for games with poor or no potential to force AA)

 For generalized explanations of what is what the glossary serves as fine information.
But for game with specific instructions it is unsatisfactory to send people there to find out information for a specific game.

[Marioysikax 89]

On 12/25/2019 at 10:59 PM, BONKERS said:

I have to draw the line that forcing SSAA,MSAA,SGSSAA,TrSSAA should be considered Hackable because these all have to hooked in at the driver level at the appropriate state during rendering. (Hence the need for compatibility bits)

It's not at all like FXAA or SMAA since those are Post Process shaders that are GPU agnostic.  You aren't just taking the final 2D Buffer like the MCable and slapping a filter on it.

 

On 12/25/2019 at 10:59 PM, BONKERS said:

In my mind that qualifies as "Hackable" because the game has no support for it, but the driver has to hook into the game engine to make it work. People visit a page for a game because they want specific information for that game. They shouldn't have to dig through other pages to eventually find information on AA for that specific game that they probably have no idea may even exist in the first place. 

This, I agree on. If you do need to actually do more work than flip a switch on something, we should have instructions at that point for that game specifically. Also as compatibility bits are essentially game specific, they should definitely count as hackable and per game basis. 

My problem is that most of the time when talking of people putting AA hackable on articles, it's because they tell to use reshade or GPU control panels FXAA option (at least I still have that there and it works, additionally there's MFAA and Inspector allows further tweaking and applying). These should work 99% across the board because it's post processing. 

We should also then have lists and guidelines that what does and doesn't count as hackable when talking of external software forcing. 

Also technically SSAA is forceable externally and globally as well with virtual resolutions? 

On 12/25/2019 at 10:59 PM, BONKERS said:

Anisotropic Filtering, I feel the same way about because tons of games don't offer it at all, their in-engine version is of lower quality(Like Crysis 2/3 for example. Even at it's highest AF in Crysis 2 is significantly lower quality than the driver verison. Similar to this Just Cause 3 comparison) or their in game option tops out at a lower setting. For games that don't have the option at all, I feel that hackable is appropriate because it's possible that your average user doesn't know they can set it up globally in the driver to override what game engines do.

Disagree.

If the game has option but it's not going to highest possible values then it should be limited (because we now have this fancy option I still kinda dislike), noted about that and then linked to AF article for instructions how to force it. 

Also if the game does not have option at all, this is exactly why hackable was not used, because false indicates there's no option for that game specifically, but then there's also note "See the glossary page for potential workarounds." with link so the user can go and see how to force it externally and/or globally. Also this way if there's game specific way of forcing AF (e.g. config files) then it's more clearly noted it being possible. 

[SirYodaJedi 14]

On 12/27/2019 at 6:12 AM, Marioysikax said:

Also technically SSAA is forceable externally and globally as well with virtual resolutions? 

Downsampling ≠ Supersampling. Yeah, I don't think "DSR" counts, but actual supersampling that isn't just tricking the game into rendering at a higher resolution should.