Adjust texture filtering presets.

[axlitEels]

Objective

• Do something about ImageSamplerDescriptor::default() not being the actual default (it's nearest instead of linear; nearest() doesn't trust default() to be nearest even though it is).
• Bring image sampler preset names to industry standard (what we're referring to as just "linear" is more precisely called "trilinear"); add bilinear and anisotropic presets.
• Make 16x anisotropic filtering an engine-wide default. The previous default is trilinear. The difference is present only with mipmapped textures, and aniso is just better looking with not that big of a performance impact.

Solution

• Reversed ImageSamplerDescriptor::default()'s hierarchy. It now returns the preset we currently consider default. Everything builds upon nearest() instead.
• Added new presets, deprecated linear() for trilinear().
• Switched the default.

[github-actions]

Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke!
You can review it at https://pixel-eagle.com/project/B04F67C0-C054-4A6F-92EC-F599FEC2FD1D?filter=PR-19127

If it's expected, please add the M-Deliberate-Rendering-Change label.

If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it.

[axlitEels]

Now that's an interesting artifact

[axlitEels]

testbed_ui that is. Replicated. Know how to fix. Don't know why that happened. With 0 depth texture, aniso shouldn't mess up anything compared to linear. The texture is just 48x48 32bit png, no mips included.

Major factor is that these elements don't have any padding and are tiny, that's why it's so intense.

Things start at examples\testbed\ui.rs, L449, the texture is textures/fantasy_ui_borders/numbered_slices.png

[axlitEels]

Although fine on modern PCs, 16x AF seems to slow down CPU rendering by up to 6 times and might also work bad on some mobile targets. I take it back, this PR is just for coherent generators.

[JMS55]

Please also update the lightmap bicubic_sampling docs.

[axlitEels]

@JMS55 why tho? We seem to be using custom interpolation code and it's actual bicubic, which is not provided by wgpu (afaik neither Vulcan or DirectX don't expose it natively)

bevy/crates/bevy_pbr/src/lightmap/lightmap.wgsl

Lines 26 to 45 in 95470df

	#ifdef LIGHTMAP_BICUBIC_SAMPLING
	let texture_size = vec2<f32>(lightmap_size(lightmap_slot));
	let texel_size = 1.0 / texture_size;
	let puv = lightmap_uv * texture_size + 0.5;
	let iuv = floor(puv);
	let fuv = fract(puv);
	let g0x = g0(fuv.x);
	let g1x = g1(fuv.x);
	let h0x = h0_approx(fuv.x);
	let h1x = h1_approx(fuv.x);
	let h0y = h0_approx(fuv.y);
	let h1y = h1_approx(fuv.y);
	let p0 = (vec2(iuv.x + h0x, iuv.y + h0y) - 0.5) * texel_size;
	let p1 = (vec2(iuv.x + h1x, iuv.y + h0y) - 0.5) * texel_size;
	let p2 = (vec2(iuv.x + h0x, iuv.y + h1y) - 0.5) * texel_size;
	let p3 = (vec2(iuv.x + h1x, iuv.y + h1y) - 0.5) * texel_size;
	let color = g0(fuv.y) * (g0x * sample(p0, lightmap_slot) + g1x * sample(p1, lightmap_slot)) + g1(fuv.y) * (g0x * sample(p2, lightmap_slot) + g1x * sample(p3, lightmap_slot));
	#else
	let color = sample(lightmap_uv, lightmap_slot);
	#endif

[JMS55]

The shader code doesn't need to be touched, but the docs should be updated to remove the reference to linear, and replace it with bilinear/trilinear (not sure if lightmaps typically use mipmaps?)

https://docs.rs/bevy/latest/bevy/pbr/struct.Lightmap.html#structfield.bicubic_sampling