Skip to main content
tmason101
Up and Coming
October 20, 2014

Accessing and using ovrPosef from different threads?

Hello,

I am wondering if anyone has any thoughts on using the data you get from ovrHmd_GetEyePose() on a separate thread for processing.

Currently the calculations for my camera and the drawing are done on the same thread but if I can move the calculations for the camera on a separate thread I can get some performance gains.

Thank you for your time.

    4 replies

    jherico
    Inspiring
    October 20, 2014
    If you want to fetch tracking data from a non-rendering thread, or outside of the BeginFrame/EndFrame calls, use ovrHmd_GetTrackingState(). GetEyePose() is pretty much strictly for use for getting a rendering pose for a given eye.

    What kind of calculations are you doing, exactly, that makes you think that doing them on the rendering thread is significant?
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
    tmason101Author
    Up and Coming
    October 20, 2014
    "jherico" wrote:
    If you want to fetch tracking data from a non-rendering thread, or outside of the BeginFrame/EndFrame calls, use ovrHmd_GetTrackingState(). GetEyePose() is pretty much strictly for use for getting a rendering pose for a given eye.

    What kind of calculations are you doing, exactly, that makes you think that doing them on the rendering thread is significant?


    Basic camera work (Projection+View Matrix) as well as incorporating physics tracking, etc.

    I already offloaded physics calculations itself to another thread and would like to have the rendering done on as tight a loop as possible without anything else beyond what is needed.
    jherico
    Inspiring
    October 20, 2014
    "tmason101" wrote:
    Basic camera work (Projection+View Matrix) as well as incorporating physics tracking, etc.

    I already offloaded physics calculations itself to another thread and would like to have the rendering done on as tight a loop as possible without anything else beyond what is needed.


    For the Rift, projection matrices are fixed, based on your FOV port. And manipulating the modelview matrix is a trivial amount of computation. For the purposes of rendering, you could use a pre-setup modelview from another thread, but the GetEyePose() calls are specifically optimized to try to return the best head pose for the next frame to be rendered.
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
    tmason101Author
    Up and Coming
    October 20, 2014
    "jherico" wrote:

    For the Rift, projection matrices are fixed, based on your FOV port. And manipulating the modelview matrix is a trivial amount of computation. For the purposes of rendering, you could use a pre-setup modelview from another thread, but the GetEyePose() calls are specifically optimized to try to return the best head pose for the next frame to be rendered.


    Thank you; trying to get the rendering done as fast as possible.

    I'll definitely get your book as soon as it is available. You always give valuable feedback.
    Terms & ConditionsAccessibility statement