Time.DeltaTime using FixedTimeStep when on Pause?

As you may know, FixedTimeStep is used for FixedUpdate and Physics update, it is independent from Update's refresh rate, but when the game is paused, and you press "next frame" the deltaTime is always the FixedTimeStep.

I noticed it when I put my FixedTimeStep to 10 (squeezing every bit of optimization I can), then I had really weird behaviour when debugging frame by frame.

I don't know if this implies something else more relevant so I thought I notify you.

 

Define 'paused'

 

http://docs.unity3d.com/ScriptReference/Time-deltaTime.html

 

Paused as in "I pressed the pause button in the editor"
It is not called from FixedUpdate.

 

That makes perfect sense. Time.deltaTime is the real-world time between two frames (modified by Time.timeScale, naturally). When you pause in the editor, the time between two frames will be one, two, ten, a hundred seconds depending on how long it's been paused, and there's no scenario where you (as a developer debugging a script) would actually want a deltaTime of 100 in that case. It has to pick a value to use for Time.deltaTime, and fixedTimeStep is a pretty reasonable one.

I guess my question is: Why would you ever set the fixed time step so high? It's just asking for trouble. Physics will be 100% worthless at that value.

 

Yeah it makes sense, but I couldn't find anything about this fact, so I thought good to make a topic about it. I don't use physics and I'm trying to save as much performance as possible. As it is impossible to completely turn off the physics engines I try to make them as absent as possible.

 

So you're saying, to make physics as absent as possible, you're just setting the time step to update so infrequently it's negligible.

OK... write an editor script that on pause it sets the timestep to whatever you want the 'frame to frame' delta to be, and on unpause it sets it back to your "optimized" value.



Do note, the physics timestep also effects triggers and their events. The physics is used for more than just newtonian physics simulation.

 

If you really don't use physics, then the fixed timestep will have zero effect.

 

The profiler tells me otherwise, unless I have some rigidbody or collider remnant. Also note I made researches before taking this decision, there is not much difference (.04ms per frame on computer) but this was roughly 5% of my process.

Thanks lordofduct, I was not really looking for a fix, but your suggestion might help me.

 

Then you don't really not use physics - there is definitely something in your scene calculating physics. Check all your rigidbodies for isKinematic, maybe? This will point you right to them:

Code (csharp):

1.  
2. void Update() {
3. Rigidbody[] allRB = FindObjectsOfType<Rigidbody>();
4. foreach (Rigidbody rb in allRB) {
5. if (!rb.isKinematic) {
6. Debug.LogWarning("Object named "+rb.gameObject.name+" is not kinematic!", rb);
7. }
8. }
9. }

 

http://d.pr/i/2pCJ
My game is 2D, never had a 3D component. Searched a rigidbody or collider in my scene: there is none. Physics.Processing still takes 0.05ms.

 

Well... huh. That was unexpected.

I'd never actually looked into this sort of thing, but I can confirm that I have similar CPU usage by Physics.Processing in the Profiler on a blank scene. Sorry about the assumption.

I may file this as a Unity bug. Physics shouldn't be doing a damn thing if there are no rigidbodies or colliders in the scene.

 

It is a known behaviour, I guess it is absolutely needed in a way or another.