Forum Discussion
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:
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?
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?
2 Replies
Replies have been turned off for this discussion
- 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 - 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.
