Add test for GltfLoaderSettings::override_sampler and mipmap rendering

[greeble-dev]

Objective

Add a test for GltfLoaderSettings::override_sampler. This also serves as a test of the renderer and mipmap filtering options.

gltf_override_sampler.mp4

Solution

#17875 recently added support for overriding texture samplers during glTF loading. This PR adds an example-based test for that feature - it loads a simple checkerboard model with various sampler settings and lets the user switch between them.

As a bonus, this also tests the rendering side of mipmap filtering. Currently there are no other tests or examples that do this.

But there's a catch! The test works by loading the same glTF multiple times, each time changing GltfLoaderSettings::override_sampler. That falls afoul of #18267 - subsequent loads of the same asset return the first loaded version, effectively ignoring the different settings of later loads.

I've confirmed that the test does work if the assets are duplicated. This can be reproduced in the PR branch by syncing to faefb8dda88ed97c9e127e5948c700c8a6275e0c.

Concerns

• Is it worth commiting a broken test?
  • Maybe this PR should be blocked on Gltf assets do not reload correctly #18267.
• Should this test be framed as a glTF test or a renderer test?
  • Arguably the glTF loader behaviour should be in a unit test.
  • Maybe this test should be renamed to 3d/test_mipmap_filtering or something.
• The test is not currently suitable for screenshot comparison.
• The test adds some assets.
  • I'm hoping this is ok as they're tiny - roughly 3KB.

Testing

cargo run --example gltf_override_sampler

Tested on Win10/Nvidia, across Desktop/Vulkan, Chrome/WebGL, Chrome/WebGPU.

[alice-i-cecile]

The test is not currently suitable for screenshot comparison.

We should try and fix this.

Should this test be framed as a glTF test or a renderer test?

Renderer test if we're going to be doing rendering and screenshots. Like you say, gltf loading should be tested purely in headless code.