Added ARRAY_TEXTURES support to shaders.

[IamTheCarl]

Objective

I and some other people in the Bevy Discord group use texture arrays. We've had to re-implement all of the pbr functionality to support this, and any change upstream breaks our code.

Solution

I have added macros that add in/swap out the few lines of code needed to support array textures.
The user still needs to implement a custom material as I haven't added any form of "StandardArrayTextureMaterial". Adding one on top of this isn't hard, but the macro #[derive(AsBindGroup)] needs to be fixed. It tries to set a fallback texture when one is set to none, and because that fallback texture is not an array texture, wgpu will fail it at validation. My workaround is to set my own fallback textures, rather than using None.

I would fix this myself but I've never written a Proc macro before and I figured I'd see if the shader changes are acceptable before going down that rabbit hole.

---

Changelog

If you create a custom material, you can add "ARRAY_TEXTURES" to your shader_defs to enable array texture support in the shaders. All textures become array textures and a "texture_layer" variable is added to the mesh_vertex_output.

Migration Guide

Standard shaders still work as expected. No migration is needed.

[ickk]

Just as a note: Array textures currently seem to have some problems on the webgl2 platform.

see gfx-rs/wgpu#3197

[IamTheCarl]

Probably not worth mentioning, but I have had problems woth areay textures on hardware from before 2010.

I wouldn't be against hiding the theoretical "ArrayTextureStandardMaterial" behind a feature flag for these reasons, especially since the use cases are a little less common. I've only really seen them used for voxel rendering.

[StarArawn]

Just as a note: Array textures currently seem to have some problems on the webgl2 platform.

see gfx-rs/wgpu#3197

There is only a problem with copy_texture_to_texture and array textures. Looking through this PR it should be fine. 🤔

[IamTheCarl]

Thank you.

For what it's worth, I've been using my fork ever since I made it and haven't had an issue with standard materials.

My changes were meant to be like that so it shouldn't be a surprise.

I do think a more elegant solution is possible but it would require some significant changes to the preprocessor and it would likely bring in issues that C's preprocessor is infamous for.

I've been wondering if the WGPU team has been considering something similar to generics for their language. It would be hard to implement but would be very elegant in this particular use case.

[IamTheCarl]

With how drastic the changes to the shaders have been, I no longer have the bandwidth to keep updating this branch.
I'm planning to rebuild my renderer without the use of this feature.