How to get elapsed physics time?

[martincmartin]

I'm computing some accelerations by recording velocities during every Update() call, recording elapsed time, and computing (currentV - previousV) / (previousT - currentT).  I'm currently using mission time as my time, but (a) it doesn't advance while on the pad (not really a problem, but) (b) when the game is paused, it increases for the first two frames after the game is paused, but the physics isn't running, so all my accelerations are suddenly zero.

What's a good value to use for physics time?  Ideally:

• Doesn't advance when the game is paused
• Take into account warp, e.g. advances 3x as fast when warp is 3x (assuming Update() is still only called once, not 3 times?)

Or is there a way to get "elapsed physics time since last call to Update()" directly?

[sarbian]

First if you want to deal with physic you do things in FixedUpdate and not Update. Update is tied to frame rate, FixedUpdate is not. 

And then you use TimeWarp.fixedDeltaTime 

Also acceleration is available in Vessel, unless you do it for something else. And if you do and use rigidbodies velocities make sure to account for the the floating origin velocity.

[martincmartin]

5 hours ago, sarbian said:

First if you want to deal with physic you do things in FixedUpdate and not Update. Update is tied to frame rate, FixedUpdate is not. 

And then you use TimeWarp.fixedDeltaTime 

Also acceleration is available in Vessel, unless you do it for something else. And if you do and use rigidbodies velocities make sure to account for the the floating origin velocity.

Thanks for the tip! I thought physics was run once per Update(), but looking more closely I see its run once per FixedUpdate():

https://docs.unity3d.com/Manual/ExecutionOrder.html

I'm actually looking for angular acceleration, I'm just differentiating angularVelocityD, I'm working on a kind of improved SAS.  I couldn't find that in Vessel, is it there and I'm not seeing it?

[martincmartin]

10 hours ago, sarbian said:

And then you use TimeWarp.fixedDeltaTime 

It turns out, TimeWarp.fixedDeltaTime is the time used in the next physics calculation.  For my purposes, where I save the previous angularVelocity and subtract it from the current one, I want the value from the prev frame, which is TimeWarp.deltaTime.

10 hours ago, sarbian said:

Also acceleration is available in Vessel, unless you do it for something else. And if you do and use rigidbodies velocities make sure to account for the the floating origin velocity.

Thanks for the tip about floating origin, I didn't know about that so I read up about it.  Where can I find the velocity of the floating origin?  I tried computing vessel.acceleration from the various velocities in vessel (velocityD, rb_velocity, srf_velocity, obt_velocity) but couldn't get the correct answer.  Perhaps correcting for the floating point origin velocity will help?

[Crzyrndm]

2 hours ago, martincmartin said:

TimeWarp.fixedDeltaTime is the time used in the next physics calculation.  For my purposes, where I save the previous angularVelocity and subtract it from the current one, I want the value from the prev frame, which is TimeWarp.deltaTime

Timewarp is basically just a wrapper on Unity's Time class with logic to handle timewarp. Details here: https://docs.unity3d.com/ScriptReference/Time.html

• deltaTime has absolutely no relation to physics calculations outside of FixedUpdate, except as a coincidence
• Both delta's are for the previously completed frame (gameplay / physics) and have no relation to the current or future frames.
• I'm of the understanding fixedDeltaTime should be invariant with the exception of phys warp (and according to Unity docs should be identical to deltaTime inside FixedUpdate calls)

By the above, recording two fixed frames back (not just one) and calculating on the stored values in combination with fixedDeltaTime should give the correct answer (but unnecesary since fixed is invariant...)

If that still appears to be incorrect, I'd be examining assumptions (are the axes assigned correctly, what units is the output in...) and/or computing your own angular acceleration from vessel.transform.rotation

RE: floating origin

velocity = part.Rigidbody.velocity + Krakensbane.GetFrameVelocity();

 

Edited November 8, 2016 by Crzyrndm

[sarbian]

Also : vessel.angularMomentum /  vessel.angularVelocity /  vessel.angularVelocityD

[martincmartin]

Thanks a lot Crzyrndm, that's very helpful.

7 hours ago, Crzyrndm said:

Timewarp is basically just a wrapper on Unity's Time class with logic to handle timewarp. Details here: https://docs.unity3d.com/ScriptReference/Time.html

• deltaTime has absolutely no relation to physics calculations outside of FixedUpdate, except as a coincidence
• Both delta's are for the previously completed frame (gameplay / physics) and have no relation to the current or future frames.
• I'm of the understanding fixedDeltaTime should be invariant with the exception of phys warp (and according to Unity docs should be identical to deltaTime inside FixedUpdate calls)

I put print("fixedDT: " + TimeWarp.fixedDeltaTime + ", deltaT: " + TimeWarp.deltaTime); in FixedUpdate(), turned warp up, and observed that deltaTime was always exactly equal to fixedDeltaTime from the previous print line.

By the above, recording two fixed frames back (not just one) and calculating on the stored values in combination with fixedDeltaTime should give the correct answer (but unnecesary since fixed is invariant...)

In FixedUpdate() I have:

Vector3d deltaVelocity = FlightGlobals.ActiveVessel.velocityD - prevVelocity;

print("accel: "+vessel.acceleration+", from fixedDT: "+(deltaVelocity / TimeWarp.fixedDeltaTime)+", from deltaT: "+(deltaVelocity / TimeWarp.deltaTime));

prevVelocity = FlightGlobals.ActiveVessel.velocityD;

Then I launch a vessel and have it go straight up (roughly constant acceleration), and warp time, and I get:

fixedDT: 0.02126373, deltaT: 0.02084686

accel: [-3.676, 0.070, 2.229], from fixedDT: [-3.615, 0.073, 2.193], from deltaT: [-3.687, 0.074, 2.237]

----------

fixedDT: 0.04007141, deltaT: 0.02126373

accel: [-3.682, 0.071, 2.231], from fixedDT: [-1.958, 0.040, 1.187], from deltaT: [-3.690, 0.075, 2.236]

-------------

fixedDT: 0.0408728, deltaT: 0.04007141

accel: [-3.848, 0.075, 2.329], from fixedDT: [-3.621, 0.074, 2.193], from deltaT: [-3.693, 0.075, 2.237]

So, if we compute using fixedDeltaTime, our computed accel is 1/2 size for a frame during the transition, but if we used deltaT, we're within a few percent, but not exact.

I'll look into the two frame back thing when I get a sec, thanks for the tip.

And thanks for the tip about the Krakensbane class, I had hear the name but didn't realize it was the name of a class!  I should have guessed.

[sarbian]

17 minutes ago, martincmartin said:

I put print("fixedDT: " + TimeWarp.fixedDeltaTime + ", deltaT: " + TimeWarp.deltaTime); in FixedUpdate(), turned warp up, and observed that deltaTime was always exactly equal to fixedDeltaTime from the previous print line.

Do the same with a 300 part vessel loaded now.

 

And your difference most likely comes from the fact that the time between your last 2 frame was still 0.02 and will be 0.04 at the next frame.

[Diazo]

Keep in mind that Update (Screen Refresh) and FixedUpdate (Physics Tick) are not sync'd.

I believe that Update tries to run 60 times a second and FixedUpdate runs 30 times a second. (Information from several unity versions ago, can not guarantee this is correct on the current version.)

What this means is that you will get inconsistent ordering, especially when the game is under load and running slower.

So you will get U-FU-U-U-FU-U-FU-U-FU-U-U-U-FU order on the updates causing all sorts of weird numbers if you try to compare the two.

The correct number should be gotten from .fixedDeltaTime as anything physics related is supposed to happen in FixedUpdate.

Note that I have done something vaguely similar and found I had to cache values from the last 5 fixedUpdate frames in a FIFO buffer and use the average as I found the numbers reported to be very "spikey" in their values and had to smooth it out to get usable numbers.

D.

 

Edited November 8, 2016 by Diazo