Improved support for WGSL shaders.

[mvaligursky]

Improved support for WGSL shaders.

Related to: #5925

Before this PR, we had limited support for WGSL shader. The shader would be passed directly to the WebGPU API, and the user would be responsible for describing uniform buffers, bind groups and similar. Using engine supplied uniforms (such as view_matrix) and similar would be hard.

An example part of a shader would look like this, where the group and binding indices as well as locations for attributes would need to be specified by the user, which required to know what the engine does under the hood.

struct VertexInput {
    @location(0) position : vec4f,
}

struct VertexOutput {
    @builtin(position) position : vec4f,
    @location(0) fragPosition: vec4f,
}

struct ub_mesh {
    matrix_model : mat4x4f,
    amount : f32,
}

struct ub_view {
    matrix_viewProjection : mat4x4f,
}

@group(2) @binding(0) var<uniform> uvMesh : ub_mesh;
@group(0) @binding(0) var<uniform> ubView : ub_view;

This PR introduces a step where we parse WGSL vertex and fragment shader (not compute shaders), and extract and automate engine integration. We introduce a simplified syntax for these elements, to closer align them with how GLSL works. The above code can now be written like this. The engine parses it and converts it to WGSL format while supplying all indices needed:

attribute position: vec4f;

varying fragPosition: vec4f;

uniform matrix_model : mat4x4f;
uniform matrix_viewProjection : mat4x4f;
uniform amount : f32;

I'll be writing a manual page for this with more details in the near future.

[MAG-AdrianMeredith]

This is a great idea but I'm also slightly concerned. As you know I had a go a while back with using wgsl shaders (plus compute) and it was tricky due to the amount of internal knowledge required to use it. A higher level api is certainly welcome but I also want to be able to use wgsl exactly as intended so that people who already know wgsl can use that existing knowledge or (in my case) read non playcanvas related material and apply that knowledge here.

My concern is that the further away from the spec the more playcanvas specific knowledge required. My biggest issue was

1. knowing what existing/built in uniforms/attributes are proved by playcanvas
2. knowing precisely how to add new ones

The less hidden magic the better tbh

[mvaligursky]

1. knowing what existing/built in uniforms/attributes are proved by playcanvas

These will be documented when I finalize this a bit more. But - if you don't want to use those, don't, those are optional uniforms that are provided, and often are needed.

2. knowing precisely how to add new ones

Again, I'll be writing a docs for this soon.

The less hidden magic the better tbh

Agreed, but shaders in every engine need to integrate with the engine's internals, and have some engine specific requirements. In this case, we're mostly just removing complicated management, without taking away any functionality. Ideally we would not, but I don't see a better option with WGSL being design the way it is, without reflection, and with a shader expected to contain slot numbers for everything that needs to match what the engine expects / needs for performance.