FOVE SUPPORT CENTER

Fove frame rate vs Unity Update

Comments

7 comments

  • Avatar
    Thomas Day

    Hi Zach,

    If you are obtaining the data using Unity's Update() method then yes, the data collection rate will be locked to the frame rate.

    However, assuming you are running at 70fps in the editor, Unity will update the frame every 0.015 seconds. This should be more than fast enough to detect whether a person is moving their eyes rapidly or if they are fixated on a specific point

    Hope this helps,

    Tom

    1
    Comment actions Permalink
  • Avatar
    Zachariah Inks

    Tom,

     

    Thanks! Yes this does answer my question, but it creates a few new ones. 

     

    So from the way you phrased things, is there a way to capture the data outside of Update in a way that does not make it as potentially inconsistent as it being associated with the frame rate?

     

    Additionally, what would be the minimum threshold for a fixation? I have read that 100 - 600ms is a good rule.

     

    Thanks again,

     

    Zach

    0
    Comment actions Permalink
  • Avatar
    Thomas Day

    Hi Zach,

    There are several update methods available in Unity. According to the Unity Documentation there is:

    Update - Update is the most commonly used function to implement any kind of game behaviour.

    Fixed Update - FixedUpdate should be used instead of Update when dealing with Rigidbody. For example when adding a force to a rigidbody, you have to apply the force every fixed frame inside FixedUpdate instead of every frame inside Update.

    Late Update - LateUpdate is called after all Update functions have been called. This is useful to order script execution. For example a follow camera should always be implemented in LateUpdate because it tracks objects that might have moved inside Update

    As far as I am aware there is actually very little difference in the execution of these different methods (They all get called per frame), However It is possible to set up Coroutines or seperate Threads to handle the data collection Asynchronously.

     

    As for the minimum threshold, I have it on good authority from a Psychology PhD Student that It depends on the context of the experiment. If you don't tell the person to fixate on a spot then 2 - 3 seconds (2000-3000 ms) should suffice, otherwise if you have the participant then you would be looking at a lot longer.

    Tom

    0
    Comment actions Permalink
  • Avatar
    Zachariah Inks

    Tom,

     

    Thanks again. Yeah I have considered the possibility of using Coroutines to get around the Update(s) issue. I guess I was more or less asking if the Fove Unity SDK package operated on the Update limitation as well. If so, then using a Coroutine would not yield any benifit as it would still be limited to the frame rate. However if the Fove did the processing in its own thread, then it could be polled more often to get non redundant data in a Coroutine. I suppose it is really a non issue if my frame rate is around 70fps, but I am just trying to understand the system better as the Unity documentation is still a bit sparse and the Unity SDK seems to be a work in progress in some ways.

     

    I will build some tests and just see what data I get back.

     

    Thanks again,

     

    Zach

    0
    Comment actions Permalink
  • Avatar
    Thomas Day

    No Problem,

    I have been trying to document the FoveUnityPlugin myself on Github as, like you said, the documentation is currently non-existent.

    I don't think you should worry about the update calls as you are currently running at 70fps which is more than fast enough.

    Tom

    0
    Comment actions Permalink
  • Avatar
    Zachariah Inks

    Tom,

     

    Thanks, I will check out your documentation and just not worry about the update for now.

     

    Zach

    0
    Comment actions Permalink
  • Avatar
    Scott Harper

    Hey,

    The Fove plugin enforces an update rate recommended to maintain sync with the HMD's display, and it does this from within a coroutine that yields on WaitForEndOfFrame() in order to make sure all animations and rendertexture cameras have been updated. It then calls into the SDK's "WaitForRenderPose" function, which synchronizes with the headset before ACTUALLY rendering the scene using the latest HMD placement information and then submitting those images to the compositor.

    Because we already handle syncing the renderer, we recommend disabling your framerate limit in Unity and letting our plugin handle that itself.

    If you want to handle input outside of the framerate, Unity's FixedUpdate function is what you want -- it run on the physics clock, which it tries to keep constant. I believe this defaults to 100 times per second, but you can customize it.

    Cheers!

    0
    Comment actions Permalink

Please sign in to leave a comment.