Why does Fixed Timestep setting affect game speed?

I wanted to change from the default Fixed Timestep of 0.02 (50 physics updates per second) to 0.01 (100 updates per second) in order to increase the resolution of my physics.

When I did this everything runs at half speed which is not what I expected because I just want to increase the resolution of my physics, not the actual game speed. I aslo though the time.deltaTime multiplier would take this into account.

If I also increase Time Scale to 2 (and Time Step at 0.01) it'll run my physics at the original rate... but then any time calculations such as life of a bullet, animation speed, and so forth is then also affected.

How would best I go about increasing the resolution of the physics engine yet maintaining realtime in my game?

 

time.deltaTime compensates for a variable frame rate. But Fixed Timestep runs independently of the frame rate to allow for consistent physics behaviour, so time.deltaTime plays no part. Physics runs at the rate defined by the Timestep, so if you change that, you change the physics.

 

The only way I can think of offhand that changing the physics timestep would affect the speed of the game is if you put code in FixedUpdate that shouldn't be there.

--Eric

 

Thanks for your replies.

I don't use anything in FixedUpdate() function yet.

My ship movement is in Update() function e.g:

Code (csharp):

1. rigidbody.AddRelativeForce(Vector3.forward * powerplantForward * Time.deltaTime);

I'm still under the impression that my ship should move the same number of meters per second regardless of the value in timestep. Am I right to have that code in Update() or should it be in FixedUpdate()? And is it correct to use deltaTime when I had a force to an object?

 

physics should always be in fixedupdate. So move any rigidbody stuff inside fixedupdate (it's what its for).

Remove * Time.deltaTime from it. You don't need that with physics, because physics are in fixedupdate, and run at a fixed rate and hence don't need deltatiming.

On your rigid bodies, you enable interpolation which will smooth them out.

Summary:

1. all physics related stuff moved to fixedupdate
2. all deltatiming removed from fixedupdate
3. enable interpolation for rigid bodies on a per body basis

 

Great - thanks for clearing that up for me. I can now set any timestep I want and the speed of the game remains the same.

Apologies for all the question...but in relation to this:

I'm using raycast bullets and they don't use physics but rather a velocity:

Code (csharp):

1. newPos += velocity * Time.deltaTime;

I found the code above in this post and it works beautifully. Now, since it's not physics and rigid objects - should I leave this in the Update() function for my bullet or should I move it to FixedUpdate() as well? If I were to move it, I'd presume I have to use Time.delaTime (which I believe uses Time.fixedDeltaTime in the FixedUpdate() function) as a divider. My tests conclude that if I don't it won't work properly since the code increments the position with a fixed velocity every time the function is executed.

I should add that this is for multiplayer and I plan to run this with an authoriative server so it would feel more appropriate to move it into FixedUpdate and use deltaTime in this case?

 

if it aint broke - don't fix it. On occasion your raycasts may in the smallest of circumstances miss a collider if the collider is moving, but this will need a pretty damn small collider moving quickly, because physics don't run at the same rate as the main thread.

Ideally, they will be in fixedupdate too (colliders are part of the physics engine) but it shouldn't actually matter at all, and certainly wouldn't break anything.

Mostly, fixedupdate is for:

1. I can't be bothered to get the timing right on this timer, I'll just throw it in fixedupdate
2. physics response, collision, and moving or overriding physics