You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was touched on in #7 and #8, and has an issue on the main spec in immersive-web/webxr#894 but I wanted to call it out in it's own issue here to ensure that it get's handled/discussed appropriately.
Unlike WebGL, which uses a [-1, 1] depth range for it's clip space coordinates, WebGPU uses a [0, 1] depth range. This means that if projection matrices that are designed for WebGL are returned from the API and used without modification the results will be incorrect.
My proposal for this is that, assuming we have a "API mode switch" as discussed in #7 the projectionMatrix of every XRView produced by the session simply begins returning the correct projection matrix for the API. Something like so:
constsession=awaitnavigator.xr.requestSession('immersive',{requiredFeatures: ['webgpu'],// Not the finalized API shape!});session.requestAnimationFrame((time,frame)=>{constviewer=frame.getViewerPose(xrReferenceSpace);for(letviewofviewer.views){constprojectionMat=view.projectionMatrix;// Is a [0, 1] range matrix because of 'webgpu' required feature.// And so on...}});
Fairly obvious, I think, outside of determining the exact mechanism for specifying the graphics API.
For the sake of completeness: Alternatives could be to begin returning a second WebGPU appropriate matrix alongside the current one (projectionMatrixGPU? projectionMatrixZeroToOne?) if we felt there was any benefit to having both, but I don't see what that would be and it would create a pit of failure for developers porting their WebXR content from WebGL to WebGPU. We could also just tell developers to do the math to transform between the two themselves, but that would be rather petty of us when we could just solve the problem so easily for developers.
The text was updated successfully, but these errors were encountered:
Yes, I think the WebXR specification should be updated to say the coordinate systems, matrices returned, etc, conform to the underlying rendering framework which is used as part of WebXR. Or alternatively, explicitly state what would be given when using WebGL and when using WebGPU.
So if WebGL is used, you get WebGL NDC spaces and appropriate matrices for use in a WebGL based rendering application.
And if WebGPU is used, you get similarly appropriate matrices for NDC space [(-1,-1,0), (1,1,1)] as indicated here along with expected depth ranges.
It would make no sense to require a WebGPU site which wants to be immersive to map back and forth between WebGL's conventions.
This was touched on in #7 and #8, and has an issue on the main spec in immersive-web/webxr#894 but I wanted to call it out in it's own issue here to ensure that it get's handled/discussed appropriately.
Unlike WebGL, which uses a [-1, 1] depth range for it's clip space coordinates, WebGPU uses a [0, 1] depth range. This means that if projection matrices that are designed for WebGL are returned from the API and used without modification the results will be incorrect.
My proposal for this is that, assuming we have a "API mode switch" as discussed in #7 the
projectionMatrix
of everyXRView
produced by the session simply begins returning the correct projection matrix for the API. Something like so:Fairly obvious, I think, outside of determining the exact mechanism for specifying the graphics API.
For the sake of completeness: Alternatives could be to begin returning a second WebGPU appropriate matrix alongside the current one (
projectionMatrixGPU
?projectionMatrixZeroToOne
?) if we felt there was any benefit to having both, but I don't see what that would be and it would create a pit of failure for developers porting their WebXR content from WebGL to WebGPU. We could also just tell developers to do the math to transform between the two themselves, but that would be rather petty of us when we could just solve the problem so easily for developers.The text was updated successfully, but these errors were encountered: