What to pass into physics.simulate for 1:1 parity with Update?

https://docs.unity3d.com/2017.1/Documentation/ScriptReference/Physics.Simulate.html

I'm doing arcade physics and I'd like my physics in sync, so what is the ideal simulate time? your documentation clearly advises against passing a variable delta, so I can't.

I don't want my update and fixed update out of sync...

 

Passing a variable timestep means you can't count on your simulations to be deterministic or super stable. But that's not necessarily the end of the world. It would be bad for games where there's a lot of "physics contraptions" such as KSP or Besiege, but in arcade-type game it would be fine.

Physics in UE4 are synced with framerate by default, presumably because it's great for fast games with tight controls like Unreal Tournament. Just be sure you give your simulation a maximum allowed timestep so that it can re-call the simulation several times in case there's a huge framerate spike. That way, you won't have physics objects doing any crazy stuff.

Here's an excellent read on the pros and cons of fixed/variable timesteps: http://gafferongames.com/game-physics/fix-your-timestep/
The "Semi-fixed timestep" part is what I'm suggesting here. I highly suggest you read the whole thing. In fact, this entire blog is a gold mine for physics and networking

And finally, here's an explanation of how UE4 handles its variable timestep: http://www.aclockworkberry.com/unreal-engine-substepping/

_________________

P.S.: Another (sketchier) option that almost never gets mentioned is to keep a fixed timestep, but always make it go at a higher rate than your maximum possible rendering framerate (75hz or 144hz for example). That way, you get all the stability of fixed timestep, with all the responsiveness of variable timestep. It'll cost you in performance, but it might be an interesting option if you have a lightweight game and you want to use that opportunity to give it 'flawless' physics response. You could add an option in the menus where the users can choose their framerate cap, and that sets both the rendering framerate cap and the physics rate to that. But it doesn't prevent users from shooting themselves in the foot by setting ridiculous framerate caps that make their game run slower than it normally could.

 

Thanks a lot for the tips

 

Alternatively, if you want to do exactly what Unity does internally, Melv's post here does the trick. No max frame time implemented there though! Either way, the links Phil have posted are generally a goldmine.

 

www.gafferongames.com is an awesome resource. Thanks for sharing!