GPU implementation differences with texture anisotropy and NEAREST filtering

[hybridherbst]

Describe the bug

Turns out #25015 has uncovered (not introduced!) a bug/inconsistency in drivers affecting three.js: when texture ansiotropy is != 1, the actual filtering mode is ignored in some implementations (but not others) and results in linear filtering being used. This is problematic for cases where NEAREST filtering was actually the intended result (e.g. pixel art). There doesn't seem to be a cross-platform way to get anisotropic NEAREST filtering; I can understand how that may be undefined.

More references:

• https://bugs.chromium.org/p/angleproject/issues/detail?id=4994
• Test aniso filter KhronosGroup/WebGL#3159
• Enabled anisotropy with nearest filtering  KhronosGroup/Vulkan-Docs#1361 (comment)

Some comments from those:

The only thing we can recommend is avoiding them: use aniso only when it will give a desired quality boost vs plain LINEAR.

if you ask for anisotropic filtering but with NEAREST or maxAnisotropy = 1.0, you get what you get

So we'll probably want to avoid that anisotropy is ever used if the filtering is NEAREST.
I'm happy to make a PR: I would probably check here

• three.js/src/renderers/webgl/WebGLTextures.js

  Line 573 in d7b1ca7

  if ( extensions.has( 'EXT_texture_filter_anisotropic' ) === true ) {

  
  if NEAREST is used and skip setting anisotropy in that case.

To Reproduce

• Set Texture.DEFAULT_ANISOTROPY to 4 (or set loaded texture's ansio to 4)
• Load this texture with NEAREST filtering:
  
• or this glb which contains the same:
  PixelArt.zip

Expected behavior

Point filtering stays point filtering, even with anisotropy enabled, users shouldn't have to know about hardware implementation bugs.

Platform:

• Device: [Desktop]
• OS: [Windows]
• Browser: [Chrome, Firefox, Safari, Edge]
• Three.js version: [dev]