Enable anisotropic filtering for 3D materials by default on desktop platforms

[Calinou]

This results in better appearance for textures viewed from oblique angles. Many other engines now enable it by default. On today's desktop platforms, the performance impact is minimal if other effects are already taxing the GPU.

The anisotropic filtering quality can be configured as usual in the Project Settings. Setting it to 1 should disable it even if individual materials have it enabled, so this is easy to revert if you don't want it.

This remains disabled by default on platforms with mobile (TBDR) GPUs for performance reasons, as texture reads are often the bottleneck there.

I see screenshots of Godot projects not using anisotropic filtering too often – let's change that! 🙂

This closes godotengine/godot-proposals#3134.

Preview

I used this Sponza demo for the screenshots. Click to view at full size, look at the floor.

Before

After

Note: the screenshot below uses 4× anisotropic filtering, not 8× which is the new default on desktop platforms.

[Logharaa]

Why is it not merged?

[Calinou]

@Logharaa reduz said on IRC he'd prefer this to be implemented in a more fine-grained fashion.

[Logharaa]

@Calinou Oh ok thanks for the info!

[reduz]

Mobile cant deal with this as well, and it needs to be tested on lower end devices too, so lets wait a bit on this one

[Calinou]

I amended the pull request to use 8× anisotropic filtering on desktop and 1× on mobile (which effectively disables it there).

[reduz]

This needs testing on low end desktop devices to ensure it makes a difference in performance or not.

[fire]

I salvaged the PR, but I'll let it simmer in my branch of Godot Engine for a bit until I submit it.

https://github.com/V-Sekai/godot/tree/vsk-default-enable-anisotropic-filtering-4.4

[Calinou]

Rebased and tested again (using @fire's work as a base), it works as expected.

I've also modified the glTF importer to handle this for material import (remember to reimport 3D scenes for this change to apply, e.g. by removing the .godot/ folder).

[Repiteo]

Codestyle checks out. Kinda surprised that anisotropic filtering wasn't already the default; always assumed it was a pretty free feature (maybe not for really low-end devices?)

[clayjohn]

I agree with reduz, this needs confirmation that it won't harm low end devices. I'm confident that it is a good change for most dedicated GPUs, but I suspect that many integrated GPUs will take a performance hit from this. Since this imposes a new default on all users, we need to be careful and validate these changes before we go ahead.

[Calinou]

I did some tests of https://github.com/Calinou/godot-sponza-4 on my laptop (on AC in balanced mode):

PC specifications

• CPU: Intel Core i9-13900H
• GPU: Intel Iris Xe / NVIDIA GeForce RTX 4060 Laptop GPU
• RAM: 48 GB (16 + 32 GB DDR4-3200 C22)
• SSD: Solidigm P44 Pro 2 TB
• OS: Windows 11 23H2

Type	master (no AF)	This PR (8x AF)
Intel, Mobile, 1152x648	296 FPS (3.38 mspf)	283 FPS (3.54 mspf)
Intel, Mobile, 2560x1600	90 FPS (11.11 mspf)	88 FPS (11.36 mspf)
Intel, Compatibility, 1152x648	490 FPS (2.04 mspf)	492 FPS (2.03 mspf)
Intel, Compatibility, 2560x1600	144 FPS (6.94 mspf)	140 FPS (7.14 mspf)
NVIDIA, Mobile, 1152x648	1510 FPS (0.66 mspf)	1487 FPS (0.67 mspf)
NVIDIA, Mobile, 2560x1600	611 FPS (1.64 mspf)	599 FPS (1.67 mspf)
NVIDIA, Compatibility, 1152x648	1695 FPS (0.59 mspf)	1727 FPS (0.58 mspf)
NVIDIA, Compatibility, 2560x1600	798 FPS (1.25 mspf)	797 FPS (1.25 mspf)

The performance difference is very small on average, especially compared to the significant gain in quality. Limiting ourselves to 8x probably did the heavy lifting here, since it's basically twice as cheap as 16x with only a slight loss in visual quality. (Console versions of games often limit themselves to 8x AF for a similar reason, since CPU and GPU memory is shared.)

Note that this is a scene with no post-processing effects applied, so scenes with post-processing will spend a greater time in areas other than anisotropic texture sampling (therefore reducing the % impact of anisotropic filtering).

[Zireael07]

What about Android devices? They're the ones which are really low-end for Godot...

[Calinou]

What about Android devices? They're the ones which are really low-end for Godot...

I've tested 8x AF on my Samsung Galaxy Z Fold4 and couldn't spot a performance difference on its main screen (it always ran at a locked 120 FPS, also on Truck Town).

However, this PR doesn't enable anisotropic filtering by default on mobile (since the .mobile feature tag override is used to set it to 1x, which is the same as disabled). We could revisit this in a future PR - I expect 2x AF to perform well on all mobile devices nowadays, maybe even 4x.

[clayjohn]

However, this PR doesn't enable anisotropic filtering by default on mobile (since the .mobile feature tag override is used to set it to 1x, which is the same as disabled). We could revisit this in a future PR - I expect 2x AF to perform well on all mobile devices nowadays, maybe even 4x.

The performance impact of anisotropic textures doesn't work like that. There is no inherent performance penalty from using it (except for on very old devices), the performance cost comes from the additional bandwidth needed to sample it. Mobile devices are often bottlenecked by reading from textures, so multiplying the cost of texture reads is prohibitive. Desktop devices are almost never bottlenecked by texture reads, so its a free quality improvement. Remember, taking more time for something that isn't the bottleneck is essentially free (until you optimize your existing bottleneck).

Low end integrated devices struggle more with texture reads than dedicated GPUs do. So we need to test there to assess the realistic impact. Testing on a high end device or a dedicated GPU won't give you any useful information unfortunately

[lyuma]

This seems good to bring Godot up to industry standard texture quality on PC platforms.

[clayjohn]

I was doing some performance profiling on macOS last week of the TPS demo and I found that anisotropic textures were a significant cause of high bandwidth in that demo. TBDR GPUs tend to get bandwidth limited fast, so increasing bandwidth is a big concern. It would be nice if this could be scoped to non-TBDR GPUs. I'm not sure if there is an easy way for us to do that.

Unfortunately this means that this PR will likely hurt performance on any ARM-based laptops as well as all mobile devices. It might be a tradeoff worth making, but I'm not sure if it is

[fire]

We discussed a long time ago where known incompatible systems degrade to a more performant setting. Unknown systems assume to work better.

[Calinou]

TBDR GPUs tend to get bandwidth limited fast, so increasing bandwidth is a big concern. It would be nice if this could be scoped to non-TBDR GPUs. I'm not sure if there is an easy way for us to do that.

If we had a way to use multiple feature tags at once in the Project Settings, we could use .macos.arm and .windows.arm as an override to disable anisotropic filtering like we currently do for .mobile.

Maybe we can disable it for .arm more generally (and keep the .mobile override in place). It is possible to use a traditional non-TBDR GPU on an ARM system (mostly on Linux with Jetson development boards), but it's a very rare use case for gaming.

[fire]

If your platform is a nintendo switch your platform provider probably wants a hook

[v1993]

From my perspective this should be a pretty easy merge in its current state, as this gives a noticeable quality boost on default settings and primarily enables proper control over anisotropic filtering (via the existing project setting), meaning that the feature isn't forced on anyone and can be easily opted out of if it turns out to cause problems for a project. I don't think there's really a need for more override options, at least for the initial merge - on desktop anisotropic filtering is traditionally exposed as a setting to end users anyways, which those with a TBDR GPU could turn down manually if they get bottlenecked by it.

[clayjohn]

Discussed in the rendering meeting this week.

I am again confirming what reduz and I both say above. This has a huge impact on performance for all non-desktop GPUs. It should not be enabled by default.

[Calinou]

Rebased and tested again, it works as expected.

I've changed the feature tag that disables anisotropic filtering from mobile to arm, for the reason I mentioned in #37847 (comment). However, it also has the side effect that when using the macOS or Android editor, you won't see a visible difference when switching between isotropic and anisotropic filters in BaseMaterial3D. (Previously, this already affected the Android editor, but the issue becomes more noticeable now that it also impacts macOS.)

It may be possible to find better criteria and create an actual tbdr feature tag. For example, this could be treated as arm, but excluded if any dedicated GPU memory is found (so that Linux ARM boards with a dedicated GPU are not seen as TBDR).

At the end of the day, there's no ideal solution here. What do other engines do by default in 2025?