Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
fight4dream opened this issue Mar 23, 2022 · 7 comments
Open

Comments

@fight4dream
Copy link

3d6a3f5

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
Copy link

barocon commented Mar 23, 2022

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
Copy link
Author

fight4dream commented Mar 23, 2022

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
Copy link

barocon commented Mar 23, 2022

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
Copy link
Author

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
Copy link
Author

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
Copy link

barocon commented Mar 23, 2022

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
Copy link

barocon commented Mar 23, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants