search

Oculus-VR / Unity-Graphics

Unity Graphics - Including Scriptable Render Pipeline
Other
63 stars 50 forks source link

(appspacewarp) Internal physics simulation time also slowed down #7

Open fight4dream opened 2 years ago

fight4dream commented 2 years ago

3d6a3f51dbcdd51296b691fd5d2040308b89215e

We have been trying out space warp in december 10 with 2020.3.23f1. :tldr: although we didn't notice the objects stuttering, we notice that all physics were slowed down.

We tried with a project using HurricaneVR, it has a crouch and jump feature with the hexa physics body. We find that we can jump much higher with spacewarp on. Then we grab things and throw them and they travel much further but the speed seems slower.

Because we can turn on/off spacewarp in runtime, we spawn and drop balls from a fixed height and observe the time it takes to hit the ground. With spacewarp on, the ball takes longer to hit the ground.

The reason we can jump higher is because while we do the crouch and stand in the same real life time, the engine (processing at a slower internal simulation time) thinks it happens in a shorter duration. thus resulting in a larger force (same distance / less time = greater speed -> high acceleration and force).

barocon commented 2 years ago

Sounds to me like a problem with too small Max allowed timestep. Have you tried changing it? I had some problems in my HVR project and I fixed it by changing to 1/60 Fixed timestep and 0.1 Max allowed timestep.

fight4dream commented 2 years ago

we haven't specifically change any time related settings between turning on/off spacewarp. and it is not mentioned in oculus dev blog doc.

the ball drop test was designed to demonstrate the problem is general and not specific to a particular plugin/framework (hurricane)

while the doc explain the tech as:

What is Application SpaceWarp? Application SpaceWarp allows an application to render at half rate from the actual display refresh rate, for example 36 compared to 72 FPS.

it is expected that the rendering is halfed, however, it is unexpected that the number of calls to FixedUpdate (physics step) is also reduced but without compensating with a longer step time.

barocon commented 2 years ago

I thought it was pretty clear that it was also running game logic at half the refresh rate. And then if your Unity Maximum allowed timestep is too tight then Unity will start skipping on physics. What's your Maximum allowed timestep at?

fight4dream commented 2 years ago

in unity it is known there are two different time concept. One being frame rate, it directly related to rendering and also anything that calls Update(). Another one being fixed time, it is related to physical simulation and calls to FixedUpdate().

by merely saying 'half the refresh rate', it should be instead send a clear message it is related to rendering (and Update()) only. and shall not be related to physics and FixedUpdate().

image current settings is 0.0111111 (1/90) for fixed timestep and 0.01388889 (1/72) for max allowed timestep, we will test if the max allowed timestep does anything.

fight4dream commented 2 years ago

i doubt it was the problem though. because the ball drop test is so simple it shouldn't have caused a heavy burden on physics calculation to make it reached the max time step.

barocon commented 2 years ago

It's not about burden. If your update is running at 36fps then it's running logic at 1/36=0,0277777777777778. Since your maximum allowed timestep is 0.013.. it will start skipping physics and make the simulation slower

barocon commented 2 years ago

You can test in on PC by capping your framerate to low fps and the same physics slowdown would appear with your max timestep settings.