WebGPURenderer: Unable to render with orthographic camera.

[Mugen87]

The WebGPU sandbox uses the following perspective camera setup:

camera = new THREE.PerspectiveCamera( 70, window.innerWidth / window.innerHeight, 0.1, 10 );

The rendered result seems as expected. However if I switch to an orthographic camera like so...

const frustumSize = 10;
const aspect = window.innerWidth / window.innerHeight;

camera = new THREE.OrthographicCamera( 0.5 * frustumSize * aspect / - 2, 0.5 * frustumSize * aspect / 2, frustumSize / 2, frustumSize / - 2, 0, 10 );

...nothing is rendered anymore.

As far as I understand, this is caused by the fact that WebGPU has different coordinate system definitions than WebGL. So in WebGPU, the z coordinate in NDC space lies in the range [0,1] whereas in WebGL it is [-1,1].

That means the current projection matrices for both perspective and orthographic cameras are not computed correctly in Matrix4 in context of WebGPU. It seems these formulas are correct: https://metashapes.com/blog/opengl-metal-projection-matrix-problem/

@mrdoob I have no idea so far how to hide this complexity from the user. When creating a camera, the projection matrix is computed right away from the parameters. In order to provide a "correct" matrix, the camera would have to know in which context (WebGL, WebGPU) it is going to be used.

[Mugen87]

Maybe introducing some sort of flag that users can set at the beginning of their code? Something like:

THREE.WebGPU.enabled = true

The camera classes could evaluate this flag and then call different implementations in Matrix4.

[mrdoob]

@Kangz

As far as I understand, this is caused by the fact that WebGPU has different coordinate system definitions than WebGL. So in WebGPU, the z coordinate in NDC space lies in the range [0,1] whereas in WebGL it is [-1,1].

[Mugen87]

BTW: I observe the exact same behavior like mentioned in the above article:

By using the OpenGL (orthographic projection) matrix in Metal, I had basically cut my view NDC cube in half and all the fragments that end up in the first half are automatically discarded.

Using the suggested projection matrix seems to solve this issue.

[WestLangley]

Maybe just premultiply the projection matrix by the appropriate transform matrix, as described in the link above, if webGPU is enabled.

[Kangz]

Premultiplying the matrix would work.

As far as I understand, this is caused by the fact that WebGPU has different coordinate system definitions than WebGL. So in WebGPU, the z coordinate in NDC space lies in the range [0,1] whereas in WebGL it is [-1,1].

That's correct. When you'll do render-to-texture there will be another difference that means that you'll need to flip-Y to keep the same rendering results as the WebGL path. (for rendering directly to the canvas there are two flips compared to WebGL that cancel out).