Repository navigation
Anti-Aliasing does not reduce aliasing / shimmer as effectively as in Ironwail #889
Replies: 9 comments 9 replies
|
Only idea i have is that it's probably something about gamma aware sample averaging. That's a setting in the NVIDIA driver that likely only applies to OpenGL these days. But honestly I have a really hard time seeing the difference on my display. Also you posted the same image twice for Ironwail, so that doesn't help either. |
|
By definition, MSAA cannot affect texture shimmering, it only antialiases edges. If the setting does reduce shimmering in IW then it is applying supersampling. Either because of a driver override or because there is a bug. Also what is the bug here? If you want supersampling, select supersampling? It's impossible to make MSAA antialias textures, so there is nothing I could do to change this |
|
@bananakid There is quite a difference between MSAA and Supersampling when I use Ironwail. Best observed with texture filtering turned off and looking at far away walls/textures while moving forward/backward. In Ironwail, Supersampling reduces shimmer a lot better than MSAA does atleast on my end. That said, both MSAA and Full AA in Ironwail look much better than the respective AA settings in vkQuake on my PC As for GPU usage, Supersampling is definitely much more intensive than MSAA in both ports. Like for example, in Ironwail I get better fps with 4x MSAA than with just 2x Full AA. Yet I still prefer the 2x Full AA since it looks better. |
|
OK As I understand it, vkQuake correctly supports antialiasing as-best-as can be, and the rest is up to specific driver settings and implementation differences between APIs and vendors. I'm converting into Discussion, because there is no bug here. |
|
I was doing a little bit of reading on this. My current understanding is that the difference is because Ironwail uses OpenGL and the MSAA algorithm for that is managed and tuned more directly by the AMD driver itself, while with vkQuake which uses Vulkan the implementation is not closely managed by the driver and the coder has to manage it more directly. AA has diminishing returns the higher resolution you go, this applies to font smoothing as well. I found a spot that you can see the difference between the two implementations.. E1M1. After you teleport in there is a slope that you will slide down if you aren't moving. If you look at the ceiling, the lines on it shimmers a lot no matter what settings are chosen in vkquake, while with ironwail there is hardly any shimmer. |
|
I repeat: Multisampling CANNOT affect texture shimmering. By definition it only changes triangle edges. This isn't debatable. So whatever you are seeing, I want A/B pictures or I will file this as placebo effect in your head. |
|
There is a chance that the AMD driver is broken and just ignores the supersampling setting. I do apply a negative LOD bias - correctly - on the textures when supersampling is on. But if the driver just ignores it that would lead to really bad shimmering and no texture AA. A screenshot would show this. If this is the case this is a clear AMD driver issue. |
|
The Windows AMD driver does correctly apply supersampling, I checked. But this is a really old GPU, is this an up-to-date driver? And what operating system? |





Uh oh!
There was an error while loading. Please reload this page.
Recently, I was comparing the AA between Ironwail and vkQuake and I noticed that vkQuake's AA looks much less effective at removing aliasing and shimmering. This is especially notable when using Full AA / FSAA in both sourceports.
Like, even 2x AA in Ironwail seems to be much more effective than 8x AA on vkQuake. I was wondering if it has something to do with my GPU or is it just how the AA works in vkQuake. If it is latter, it would be much better to have AA like that of Ironwail.
As for my hardware.
Laptop: Dell Inspiron 5570
Dedicated GPU: AMD Radeon 530 (Polaris generation)
Intergrated GPU: Intel UHD 620
CPU: Intel i5 8250U
RAM: 8 GB
All reactions