Repository navigation
Set Application.targetFrameRate to display refresh rate #50
Description
Application.targetFrameRate should be set to the refresh rate of the display. I believe the plan is for this to be added to the display descriptor along with other properties necessary for rendering updates.
Might also want to consider setting Time.fixedDeltaTime to 1/Application.targetFramerate. Our default TimeManager.FixedTimestep is set to 0.016667 or 60Hz, but someone using a DK2 might want this set at 75Hz.
http://www.reddit.com/r/oculus/comments/2odahu/unity_developers_change_your_fixed_timestep_to/
http://docs.unity3d.com/Manual/TimeFrameManagement.html (fixed timestep section)
Activity
heptamind commentedon Jun 5, 2015
I don't think we need to change the Time.fixedDeltaTime, as it is independent from rendering framerate. It is used for physics and related things.
Edit: I should have read the reddit post before commenting...
I still think we should leave it to the developers using OSVR and maybe mention it in our readme file.
rpavlik commentedon Jun 5, 2015
Once/if this data is available from the display, it seems reasonable to do this.
chase-cobb commentedon Apr 1, 2016
Why not turn on vsync in this case?
Fixed timestep is adjustable by the developer, and should be to optimize physics. This is also affected by modifying the time scale.
http://docs.unity3d.com/ScriptReference/Time-fixedDeltaTime.html
DuFF14 commentedon Apr 1, 2016
Vsync should be enabled in RenderManager, but having it on in Unity is a choppy experience for me. The fixed timestep thing was something that developers were recommending that seemed to make things feel better (sometimes?).
I had an issue open regarding looking into the timing of Unity's vsync setting. Dunno if it's worth re-opening the issue, it's more of a to-do #76
chase-cobb commentedon Apr 1, 2016
The fixed timestep is a slippery slope and I would caution against it. It primarily changes the resolution rate of physics interactions. So in physics heavy games it can drag performance way down, if the game is already on the fence. Ideally, developers should be able to freely tweak this setting to best suit their game/experience.
Can the server expose the display timings to the client? That seems like a more scale-able solution.
DuFF14 commentedon Apr 1, 2016
A DisplayInterface is on the roadmap for 1.0, not sure what the current status is OSVR/OSVR-Core#35
I think we could get the value from RenderManager as a workaround. Did a qucik test in Unity Palace Demo -- if I set Application.targetFrameRate to 75 and run in DirectMode on the DK2, it looks much better (less tearing) than if the framerate is not set (the default right now).
I don't know if the timestep trick is still applicable, that was from before we had a RenderManager and might even have been a bug in an earlier version of Unity where Physics interpolation was not compensating for Physics update rates that were slower than the refresh rate. I agree we should leave it up to developers to set it, but it's worth noting if there's an observed effect in Unity.
As a side note, the asset store version comes with the uploaded Unity Project Settings because it's in the "Complete Projects" category on the Asset Store. I'd prefer to be in the "Scripting" category and have an in-editor gui for changing any relevant project settings, similar to the SteamVR Unity plugin.
DuFF14 commentedon Apr 5, 2016
It looks like SteamVR has an option for setting the physics update rate equal to the display refresh rate, on by default, and Application.targetFrameRate = -1
https://github.com/ValveSoftware/openvr/blob/master/unity_package/Assets/SteamVR/Scripts/SteamVR_Render.cs#L397