Natural Opinions

An Archive Of My Thoughts

SSAA sometimes causes blurring when the framebuffer isn't properly setup for whatever grid/shader or filter is being used.  It often collides with post-processing effects.  Unfortunately this has become quite common in todays games. The only fix is to figure out the correct combination of AA compatibility bits to use to make the framebuffer more compatible. And sometimes that is a difficult task. In some games though you'll get lucky and the default AA compatibility bits for that game profile will work flawlessly, if not try looking it up online.

If you don't believe me boot up quake III and try out one of the hybrid modes (since the pure XxX SSAA modes don't work with opengl).

If the game is already setup properly for SSAA it is a godsend. SSAA makes textures crisper/clearer/sharper, gets rid of all texture aliasing/shimmering (makes anisotropic filtering look like a joke by comparison), gets rid of shader aliasing that MSAA doesn't affect which has become extremely common in todays games, gets rid of polygon aliasing, gets rid of aliasing on shadows (usually, some games have some funky techniques for shadowing) and transparent textures, and allows you to use a lower LOD bias if you want for even better texture quality (it makes a really big difference in some games and little difference in others). The imperfections such as aliasing and texture inconsistency are so annoying to me that I will take SSAA + lower settings over MSAA + higher settings in any game any day. Personally I use 16xS (4xSSAA + 4xMSAA) whenever possible, I find it has the same IQ as 16xSSAA but I can use it with a lot more games due to the significant difference in performance and that fact that it works with opengl even on older cards. If you're trying to get good performance in a newer game 4xMSAA is still the best balance between performance/IQ.

 Everything will still look extremely blurry no matter how low you set the lod bias if the compatibility bits are wrong. And vice versa, if the compatibility bits are correct everything will look clear as day even without a lod bias adjustment.

A negative lod bias will improve texture quality either way but if the bits are wrong it will still look worse than with SSAA off.

Back when I first discovered nhancer and started playing around with SSAA in modern games I too was wondering why SSAA made things blurry. When I started digging online I saw the same thing everywhere "it's because you need to lower your lod". Everyone talked about SSAA as if it was inherently supposed to make everything blurry because of how it works, despite the fact that if you think about that for 2 seconds it makes no f**king sense at all. I mean if you run a game at 1600 x 1200, take a screenshot and shrink the image to 800 x 600 do you think that image will look much blurrier than if you run the game at 800 x 600 and take a screenshot? Of course not. Well I tried lowering the lod bias, and it made no significant difference with high amounts of SSAA. Yet I knew it was working since if I turned off SSAA it caused massive amounts of texture shimmering. I was also wondering why some games looked sharp with SSAA while others were blurry. If SSAA is SUPPOSED to make things blurry then why would that happen? That's when I started playing with AA compatibility bits and discovered the truth. To this day the only forum I have ever seen where the average user understands the real reason why SSAA is blurry in some games was a german 3d developer forum. IT HAS NOTHING TO DO WITH TEXTURES OR TEXTURE FILTERING.

 Both nvidia inspector has seperate comp. bits for d3d9 and d3d10/10.1/11 take a look:

The bits are preset but you don't have to use the nvidia profiles. You can create custom comp. bit profiles by turning the individual bits on or off and making different combinations, which a lot of people do. See:

Check here (the forum is in german):

Yes 2x2 SS is 4xOGSSAA. As in a scale of 2x is applied to the framebuffer dimensions along both the x and y axis. The S in 32xS stands for supersampling, as in it has an SSAA component not just MSAA. 32 samples without any SSAA would just be listed as 32x (which is 8xMSAA + 24xCSAA). SGSSAA renders the scene to multiple intermediate buffers with several passes, an offset to the sample coordinates is applied at each pass and then the buffers are read by a post-processing box filter to fill the backbuffer (the framebuffer that is scanned out to the display at each refresh).