Implement bindless lightmaps.

[pcwalton]

This commit allows Bevy to bind 16 lightmaps at a time, if the current platform supports bindless textures. Naturally, if bindless textures aren't supported, Bevy falls back to binding only a single lightmap at a time. As lightmaps are usually heavily atlased, I doubt many scenes will use more than 16 lightmap textures.

This has little performance impact now, but it's desirable for us to reap the benefits of multidraw and bindless textures on scenes that use lightmaps. Otherwise, we might have to break batches in order to switch those lightmaps.

Additionally, this PR slightly reduces the cost of binning because it makes the lightmap index in Opaque3dBinKey 32 bits instead of an AssetId.

Migration Guide

• The Opaque3dBinKey::lightmap_image field is now Opaque3dBinKey::lightmap_slab, which is a lightweight identifier for an entire binding array of lightmaps.

[JMS55]

For binding_arrays_are_usable() we don't require PARTIALLY_BOUND_BINDING_ARRAY, but I don't see any padding of slabs with dummy textures to ensure the binding array is full.

[pcwalton]

Dang it, I even made a note to remember to do that and then forgot anyway :)

I now pad out the lightmap slabs to their maximum size.

[pcwalton]

The latest merge ran this PR out of space in the MeshInputUniform and MeshUniform. I fixed it by packing the material bind group slot and lightmap slot into a single 32-bit integer. Since the maximum size of each is 16 by default, this gives us plenty of space.

[github-actions]

Your PR increases Bevy Minimum Supported Rust Version. Please update the rust-version field in the root Cargo.toml file.

[bushrat011899]

The Rust code looks fine to me (no comment on the WGSL as I'm unfamiliar with the language). I tried running this branch locally with the testbed_3d example on Windows 10 with an i5-1240P iGPU and encountered a crash which I'm not experiencing on main.

Tested using $env:WGPU_BACKEND="dx12"; cargo run --example testbed_3d and can render the first two scenes fine, but the 3rd scene (gas mask) crashes with the following log:

     Running `target\debug\examples\testbed_3d.exe`
2024-12-12T01:05:31.383756Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "Windows 10 Pro", kernel: "19045", cpu: "12th Gen Intel(R) Core(TM) i5-1240P", core_count: "12", memory: "31.7 GiB" }
2024-12-12T01:05:31.453262Z  INFO bevy_render::renderer: AdapterInfo { name: "Intel(R) Iris(R) Xe Graphics", vendor: 32902, device: 18086, device_type: IntegratedGpu, driver: "32.0.101.5972", driver_info: "", backend: Dx12 }
2024-12-12T01:05:32.052131Z  INFO bevy_winit::system: Creating new window "App" (0v1#4294967296)
2024-12-12T01:05:37.295522Z  INFO testbed_3d: Switching scene
2024-12-12T01:05:41.643572Z  INFO testbed_3d: Switching scene
thread 'Compute Task Pool (6)' panicked at crates\bevy_pbr\src\render\mesh.rs:989:49:
index out of bounds: the len is 1 but the index is 2
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `bevy_pbr::render::mesh::collect_meshes_for_gpu_building`!

This PR does modify the file listed as the source of the panic, so it may be caused by this PR. I tried switching back and forth between different branches to confirm. Please reach out to me if there's something I can do to help diagnose!

[pcwalton]

@bushrat011899 That sounds like something that was fixed on main recently. I can't reproduce after merging with main. Could you try again with the newest version of this PR?

[bushrat011899]

Can confirm this is no longer an issue, I'm able to cycle all scenes in testbed_3d