Skip to main content
eodabash
Participant
May 6, 2014

Projection offset matrices in 0.3.1 SDK

With the 0.2.x SDK I had my stereo rendering code working using the sample code from the docs to calculate the left and right projection offsets with code like this:

float viewCenter = hmd.HScreenSize * 0.25f;
float eyeProjectionShift = viewCenter - hmd.LensSeparationDistance*0.5f;
float projectionCenterOffset = 4.0f * eyeProjectionShift / hmd.HScreenSize;
// Projection matrix for the "center eye", which the left/right matrices are based on.
Matrix4f projCenter = Matrix4f::PerspectiveRH(yfov, aspect, 0.3f, 1000.0f);
Matrix4f projLeft = Matrix4f::Translation(projectionCenterOffset, 0, 0) * projCenter;
Matrix4f projRight = Matrix4f::Translation(-projectionCenterOffset, 0, 0) * projCenter;

Now I'm attempting to integrate the 0.3.1 SDK to use the SDK distortion rendering, but the examples in the docs seem to now be using the new C API and I can't figure out how to access the same information I used to get from the HMDInfo struct through this API. I see the ovrMatrix4f_Projection function being used in the new sample code but this appears to be generating the entire projection matrix, which is not really practical for me to do.

Is the old method of calculating the left and right offsets no longer applicable in the new SDK, or is it just not compatible with the C interface and/or SDK distortion rendering? Do I need to mix the two APIs to accomplish what I'm trying to do? If anyone could help clarify this for me it would be much predicated.

Thanks,

Evan

    3 replies

    jherico
    Inspiring
    May 6, 2014
    "eodabash" wrote:
    Is the old method of calculating the left and right offsets no longer applicable in the new SDK, or is it just not compatible with the C interface and/or SDK distortion rendering?


    The new projection matrices for rendering are substantially different than the old ones. Previously, the SDK just used the offset of the lens axis from the center of the screen to shift where 'forward' was in the image so that it landed under the lens axis. This means a little less than 45% of the pixels rendered were on the inward side of the image.

    However, this ends up wasting pixels. Each eye sees an asymmetric view of the world, with substantially less field of view for the inward side of each eye.



    The new mechanism of distortion distorts pixels based on their angle of offset from the eye, which is calculated in conjuction with the new projection matrices and new FOV calculations. The new projection matrix is calculated by providing an FOV port (similar in concept to a viewport, but using angles of view from the forward direction, instead of pixels). The FOV port values that come out of the HMDDesc structure you can get from the C API favor the outward directions more, meaning only about 30% of the pixels rendered are devoted to the inward directions. However, this means that these images can't be used with the old distortion code, nor can code that uses the old projection matrices be used with the new distortion mechanism... almost.

    "eodabash" wrote:
    Do I need to mix the two APIs to accomplish what I'm trying to do? If anyone could help clarify this for me it would be much predicated.


    If you want to continue using the old projection matrix code but use the new distortion mechanism, you would need to create an FOV port structure that matches the FOVs provided by the old projection offset mechanism. However, this sounds error prone and annoying.

    "eodabash" wrote:
    I see the ovrMatrix4f_Projection function being used in the new sample code but this appears to be generating the entire projection matrix, which is not really practical for me to do.


    Can you explain why this is impractical? You're generating the projection matrix in your example code right there, so I don't see why replacing the call to Matrix4f::PerspectiveRH with an ovrMatrix4f_Projection call would be a big problem.
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
    eodabashAuthor
    Participant
    May 6, 2014
    We develop an SDK so normally the user describes the camera to us through our API and not by directly giving us a projection matrix. I've been trying to emulate integration of the Rift from mostly user code (not building our libraries against the Rift SDK) and was I was originally planning to just let them give us the view and projection offsets as a correction to our normal transforms.

    However If letting the Rift SDK calculate the projection matrix is critical to getting optimal results we'll figure out a way to work with it. Thanks for clarifying these changes for me.
    jherico
    Inspiring
    May 6, 2014
    Yeah at this point, if you're working with the Rift, then setting up the projection matrices boils down to 'what do you want the near and far clipping planes to be' or 'how deep do you want your ortho projection matrix to place items'.
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
    Terms & ConditionsAccessibility statement