-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
GetProjectionRaw returning unconventional values? #23
Comments
Why not use the conventional provided projection via "Most games should use GetProjectionMatrix instead of this method, but sometimes a game needs to do something fancy with its projection and can use these values to compute its own matrix." https://github.com/ValveSoftware/openvr/wiki/IVRSystem::GetProjectionRaw |
In case anyone sees this later, the values returned by GetProjectionRaw are actually the tangents of the half-angles from the center view axis to the respective clip planes. I assume this is because then the API doesn't need to take in a value for the near plane distance, like most APIs that provide 'left right top bottom' values for projection matrix generation, with the assumption that those values lie on the near plane itself. If you look at the documentation for XMMatrixPerspectiveOffCenterLH, you can see that the 'lrtb' coordinates are defined as being on the near clipping plane. As for why the OpenVR API decided to use the tangent of the half-angles, I think it's because it elegantly generates other useful values easily. Do you need the FOV? You can use arctan to get the radians of the half angle. Do you actually want the 'lrtb' coordinates in view space? Simply multiply them by your near plane distance. For example: The only quarrel I have with the API is that it doesn't really make note that they are tangent values. I updated the wiki, hopefully that helps! |
Hello, can you help me here: Modify GetProjectionRaw from a console application |
When calling GetProjectionRaw the values return work well with the ComposeProjection method as specified in the docs.
However they are unconventional to say functions like:
-glFrustum
-D3DXMatrixPerspectiveOffCenterLH
-XMMatrixPerspectiveOffCenterLH
To compute the projection using any of the functions above, all values returned by GetProjectionRaw will have to be multiplied by the near clip plane. Also, top and bottom value need to change sign.
Is there a reason not to follow this convention ?
The text was updated successfully, but these errors were encountered: