Forum Discussion
OpenGL Stereo Camera Setup and Convergence
Edit: I think that my baseline needs to change to get rid of the 0.5 up front, but everything else still broken: float const baselength = near_ * std::tan(M_PI * (fov_/2.0 / 180.0)); I've been stuc...
Hi all, I just discovered this same problem, where the frustum creation is different in the SDK (in particular, in CreateProjection() in OVR_Stereo.cpp), compared to the usual OpenGL (and GLM) calculation.
If you "do the math", you'll find that the Oculus SDK way is like DirectX, where Normalized Device Coordinates range from 0 (near) to 1 (far) in Z. In OpenGL, the NDC range is -1 (near) to 1 (far). That's the only difference between these two calculations:
vs:
If you use these two projection matrices to project a homogeneous point (0, 0, -zNear, 1) (then divide by w), in the first case you'll get a projected z coordinate of 0; in the second case, -1. Projecting a point at (0, 0, -zFar, 1) in both cases results in a z NDC of +1, as expected. What does this mean, in practical terms? Not sure -- I guess it means you're "wasting" some of the depth buffer resolution for very near objects?
Glen.
If you "do the math", you'll find that the Oculus SDK way is like DirectX, where Normalized Device Coordinates range from 0 (near) to 1 (far) in Z. In OpenGL, the NDC range is -1 (near) to 1 (far). That's the only difference between these two calculations:
projection.M[2][2] = -handednessScale * zFar / (zNear - zFar);
projection.M[2][3] = (zFar * zNear) / (zNear - zFar);
vs:
// "Corrected" code (for OpenGL, not DirectX!)
projection.M[2][2] = -handednessScale * (zFar + zNear) / (zNear - zFar);
projection.M[2][3] = (2.0 * zFar * zNear) / (zNear - zFar);
If you use these two projection matrices to project a homogeneous point (0, 0, -zNear, 1) (then divide by w), in the first case you'll get a projected z coordinate of 0; in the second case, -1. Projecting a point at (0, 0, -zFar, 1) in both cases results in a z NDC of +1, as expected. What does this mean, in practical terms? Not sure -- I guess it means you're "wasting" some of the depth buffer resolution for very near objects?
Glen.