-
Notifications
You must be signed in to change notification settings - Fork 266
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong view projection matrices #517
Comments
when I run the depth buffer locally I do not see anything but a black screen. When I run in the browser it works just fine. Do you have any insight into how I might fix that? I just had to struggle for two days trying to figure out why my ray-sphere intersection was not working only to find out I needed to remove the |
I'm considering removing |
How would you go about removing it? I assumed it was necessary for normalizing the z axis properly. |
I believe it's meant to move the projection forward and scale it in the z by 2. Opengl has the z buffer between -1 and 1 while wgpu has it between 0 and 1. To be fair I'm not sure about the specifics, but removing it from the camera calculation made the skybox code work. I could have had add an extra matrix to the uniforms or something similar, but removing it worked fine. I wouldn't be opposed to switching to |
The view proj matrices in the course don't provide far clipping. Projecting a point at dist = far_plane returns 0.33.
After comparing with wgpu examples, for the same parameters, the computed matrices are indeed different, and their matrices return the correct depth. This also affects xy that are 33% smaller in learn-wgpu, resulting in a smaller fov.
#478 transposed
OPENGL_TO_WGPU_MATRIX
but reverting this change fixes the discrepancy between the two libraries, both for perspective and orthogonal matrices, fixing the issue.I lack insight to know what was the issue in #478, but without more analysis, I think it's better to revert the change to be aligned with wgpu examples and get a correct depth/fov back.
On a side note, wgpu examples use glam, a "wgpu-ready" linalg crate with bytemuck integration and only has specific functions for gl matrices, wgpu being the default. I think it is a good alternative to consider to be more pure wgpu. I'm willing to look into it if you agree with my sentiment.
I'm copying the comparison code here for reference, and the archive in a zip file:
Comparison code
learn_wgpu_matrices.zip
The text was updated successfully, but these errors were encountered: