Reusable PBR shader types/bindings/functions

[superdump]

Description

• As of 0.6, the approach to importing the core PBR shader functionality is unclear but we want them to be reusable, whether due to people having PBR data that they need to obtain from different bindings, or if they want to customise the shading code. The story around how to do these kinds of things should be clear to enable flexible reuse and extension.

Solution

• Reusable PBR shader types/bindings/functions #3969
• Split mesh view, mesh, and pbr shaders into types, bindings, and functions. The purpose of this is to allow reuse of types and functions without bindings, or types and bindings without functions, or all three, or whatever you like.
• Move all normal and view vector calculation into separate functions to make them callable
• Add mesh coordinate space transformation functions to support consistent calculation of world/clip positions and normals. Particularly clip positions are important due to using the equal depth comparison function for geometry with opaque or alpha mask materials in the main 3D passes.
• Add PbrMaterial and PbrInput pbr types that contain all the material and fragment stage input information needed by the core pbr shaders
• Add a pbr() shader function and pass all variables and bindings as arguments. Functions within the pbr() code path have to reference 'global' bindings directly due to the way shader programs / WGSL work.
• Add back the array_texture example and leverage the imports, mesh position coordinate space transform functions. This could/should be extended to call into the pbr() function to demonstrate using the core pbr functionality with custom inputs.

[superdump]

I investigated this some more and discovered that it was 'just' really slow. You cannot pass uniform buffers as function arguments without it generating a ton of instructions to copy everything from the uniform buffer. That's maybe fine for small buffers but it doesn't work well at all for the clustered forward bindings.

Apparently WGSL is designed for a WGSL compiler to not have an 'inliner' which would otherwise, to my poor understanding, instead of copying data being passed into a function, lift the function code body out to refer to the data directly. Something like that, but I recognise I'm being hand-wavy.

So, tl;dr - in WGSL we will have to refer to the binding variables directly from deep within code paths. I'll revert that last commit and move on.

[superdump]

Closing as the foundation has now been laid for reusing the PBR shader types/bindings/functions.