Skip to main content
hedgehog
New Participant
July 10, 2013

Input processing very slow with OVRCameraController

I've got a snowboard-game using the Wii Balance Board as an input device.
I've got a First Person Controller with two cameras attached to it. An ordinary Camera and a OVRCameraController.
I can switch in-game between both cameras.

Attached to my First Person Controller is my movement-script:

void FixedUpdate () {
    // Rotate the board
    Debug.Log (Time.deltaTime);
     transform.Rotate(0, -40 * theCenter.y * Time.deltaTime, 0);
}


Both cameras sport the same clipping planes and render with similar framerates (normal camera 44 FPS vs OVRCameraController with 30 FPS).

However the board rotates much slower with the OVRCameraController active. Since I'm using FixedUpdate I can only guess why.

When trying to isolate the problem I found out that the I get a fluid rotation when I disable the OVRCamera scripts of CameraLeft and CameraRight.

Does anyone have a clue what is going wrong here?
    This topic has been closed for replies.

    2 replies

    bradherman
    Up and Coming
    July 10, 2013
    You game idea sounds like a blast. What drivers are you using to make the Wii Balance Board work?

    I have a few ideas, however you may have already looked into these:

    The FPS hit is because you are rendering 2 images, left eye and right eye. That's a pretty common thing to deal with.

    Try turning off your log function, running those in both update and fixedupdate can be a noticeable performance hit.

    Is that 100% of your code in FixedUpdate? Are you also doing math above it to figure out what theCenter.y is? Or is that coming from somewhere else? If your calculations that happen durring fixed update take longer than the update delta you can get into some odd laggy behavior.

    2 Good posts on this:
    http://answers.unity3d.com/questions/202614/and-yet-more-questions-about-fixedupdate.html
    http://answers.unity3d.com/questions/10993/whats-the-difference-between-update-and-fixedupdat.html
    CaliberMengsk
    Up and Coming
    July 11, 2013
    Definitely disable any Dubug.log that you have. This will lower performance a ton. (it's actually writing to the hard drive when you do a debug.log, not just outputting it, hence why it's slow.)

    I've noticed that deltatime is actually fairly inaccurate at extreme high, and semi-low framerates in unity. At least in the editor. In a 2.5d side scroller, 10fps compared to 60fps can change how high the player can actually jump (in some cases I've noticed the player jump not even half the height of a normal jump). I'm not sure why this happens, but I think it has to do with the float value being limited to only 8 or 10 decimal places, and when you go so fast, it just rounds it. I'm also fairly certain there is a maximum limit to delta time, so at very low framerates, it limits it to .02, or something like that.

    Best thing to do is try and keep it at 60fps, by turning on vsync or setting the framerate target.
    http://docs.unity3d.com/Documentation/ScriptReference/Application-targetFrameRate.html

    You can also test extremely low framerates with this (just use a script to set the framerate, and check it by using a GUI.Label to output 1/Time.deltaTime to get the framerate).

    Hope that was a bit informative. Just note that there are bugs like that.
    Current Project: Virtual Reality Glove project
    Terms & ConditionsAccessibility statement