WebGPURenderer: Align depth range of WebGPU and WebGL backends

[RenaudRohlinger]

Description
When overriding the depthPixelBase, both backends display different behaviors related to their distinct depth ranges, with WebGPU being [0, 1] and WebGL being [-1, 1].

It seems that without extensions such as EXT_depth_clamp, WebGL internally clamps these values to the range [0, 1] during the rasterization process. So, I believe that it wouldn't be wrong to handle it internally, ensuring that if a user overrides the depth of a material, both backends will show the same result.

Edit: Or should we do the opposite and handle WebGL depth range first? I'm not sure, it seems that the case is very variable on if we want to handle it manually. For example the issue I was solving there was that using 0.5 * modelViewMatrix.z / modelViewMatrix.w + 0.5 breaks in WebGPU as it should be modelViewMatrix.z / modelViewMatrix.w.

This contribution is funded by Utsubo

[sunag]

Edit: Or should we do the opposite and handle WebGL depth range first? I'm not sure, it seems that the case is very variable on if we want to handle it manually. For example the issue I was solving there was that using 0.5 * modelViewMatrix.z / modelViewMatrix.w + 0.5 breaks in WebGPU as it should be modelViewMatrix.z / modelViewMatrix.w.

The WebGPU specifications will always be the basis for all WebGL variations in WebGPURenderer, for this your current implementation seems correct to me. I was just wondering, according to the explanation, can we use the EXT_depth_clamp extension and check if it is not available in setup() and then apply the path?

[RenaudRohlinger]

I believe that's not an issue anymore.

Reading back my comment:

It seems that without extensions such as EXT_depth_clamp, WebGL internally clamps these values to the range [0, 1] during the rasterization process

I think it might be worth it investigating a EXT_depth_clamp/EXT_clip_control fallback for the WebGL Backend (related #29445).