In the OculusMobileUnityIntegrationGuide.pdf, we're instructed to set both the "Fixed Timestep" and "Maximum Allowed Timestep" to 0.0166666 (under Edit->Project Settings->Time). According to the Unity docs, this is for the physics and FixedUpdate() interval.
However, setting the "Maximum Allowed Timestep" also appears to cap the deltaTime that is used in the regular (non-fixed) Update(). This means that if your game isn't quite hitting 60fps, using Time.deltaTime in Update() will return at most 0.0166666, even if longer than that has elapsed in the real world. This cap on deltaTime prevents it from being framerate independent (when running at <60FPS).
We have very little in the way of physics in our game, but we do have a beeping timer on our time bomb that makes it very obvious when "time is running slowly". Increasing the max timestep allows Time.deltaTime within Update() to be larger, which suits our needs. On device this seems to still work well, with timewarp compensating nicely for any dropped frames.
Obviously a rock solid 60fps would be preferred, but how important is keeping the "Maximum Allowed Timestep" at 0.0166666? Is it necessary for timewarp to function properly (and maybe we're just not noticing a problem)?
edit: It may be that limiting the timestep was only meant for the physics-centric Blocksplosion example and not as a guideline for all games. If that's the case, then we'll just use a slightly larger max timestep and move on.
"bkane" wrote: Obviously a rock solid 60fps would be preferred, but how important is keeping the "Maximum Allowed Timestep" at 0.0166666? Is it necessary for timewarp to function properly (and maybe we're just not noticing a problem)?
I'd love to know this as well. I ran into the same issue with my deltaTime-based animations slowing down in sub-60 FPS, and decided to switch to calculating my own delta as the time between Time.realtimeSinceStartup and the last frame's Time.realtimeSinceStartup.
But like you said, 60 FPS+ is preferable. 🙂
Titans of Space PLUS for Quest is now available on DrashVR.com
The goal is to have your app running at a solid 60fps, updating all game/app logic each frame.
Obviously not all apps need physics running at 60fps. In fact, some games/apps might perform better not running the physics that often. I think having Time.deltaTime capped at 0.016666 regardless of how long a frame has taken is indeed a problem that might need to be revisited and/or documented. Time warp should help eliminate discomfort for the user when there's a momentary drop in frame rate, however, you should strive to eliminate those situations.
In other words, on this, your mileage may vary. I'd set it to whatever makes your app perform the best.
The call for setting this was made for the original SDK, before we had async Time Warp, where anything that wasn't at 60 fps was unusably juddery. With async time warp, we tolerate dropped frames, so we should probably remove this advice, or note that it may be detrimental for apps that don't hold a really solid 60.
