Could someone explain the "Max physics delta-time per frame"

[panzer1b]

Well as the title says, i know the general idea of what it does (alters the time spent for physics per frame) in general, but what does this translate to in a practical sense in game?

Ive heard people say to move the slider towards 0.03 (or even edit config to smaller values) to make lag go away, but ive had some better results setting it to a higher value.  My scenario involves 2 capital ships (each ~300 part), which lag considerably when brought into a broadside shootout.  The lag is WORSE using the recommended setting of 0.03 then say 0.06 which im running on right now.  Why am i getting better results going against the common suggestion of lower this velue to lower lag?  Does anyone actually know what the heck this setting really does, cause it seems to be rather random, 0.03 lags more then some mid range values of 0.06, while 0.12 seems to make the game freeze-frame when dealing with large vessels.  And by what it does, i mean a more in depth understanding of what this setting changes with the phys engine, and what kind of performance improvements it gives/doesnt give with various settings?

Also, with my tests its more of a feeling, i dont have any hard data to measure (its not like KSP comes with a handy FPS measuring system that i can do tests with), but from my experience setting it above 0.03 is less laggy overall whatever that means.

[steve_v]

10 minutes ago, panzer1b said:

its not like KSP comes with a handy FPS measuring system that i can do tests with

There's an FPS graph in the debug (mod+F12) toolbar. For the rest, I agree with your observations, but I don't know the code well enough to explain why.

[Moesly_Armlis]

Please excuse the crudity of this model. I didn't have time to build it to scale or paint it.

Large step size means less steps and less calculations. The large skewers complete the half circle in six steps with a diameter of four. The large steps reveal a rough estimate of π. 

Twenty six toothpicks to complete the half circle and diameter of sixteen. Smaller steps need more steps and therefor increase load on the CPU because of the increase in number of calculations. The small steps provide a closer approximation to π.

 

 

Using a higher value for Max Delta Time per Frame will lessen the load on the CPU and increase enjoyment; the game will lags less when high part count vessels are loaded.

[panzer1b]

Interesting, so its actually the opposite of what many people say to set it to a very low value to get rid of lag, and great explanation with the toothpicks .  Im assuming the physics is more accurate with a lower value, but less accurate and more choppy with a higher value.  Gonna try 0.12 then, although for some reason the game seems to get choppy at that setting from my experience.  I think the best setting is kinda middle of the road though, so its neither one extreme nor the other.

Now all we need to figure out is a way to make the game function at higher then 10FPS when there are 2 1000 part dreadnoughts loaded at the same time!

[NathanKell]

Uh...I'm pretty sure none of that is right. The value that is set is this one. The larger that value, the slower your visual FPS can be (but the closer to realtime physics will be); the smaller that value, the slower game time will be compared to realtime, but you'll have a higher visual FPS.

Remember, physics frames aren't the same as visual frames.

[Moesly_Armlis]

1 hour ago, NathanKell said:

Uh...I'm pretty sure none of that is right.

Are you saying that is not how to approximate the value for π?

[pincushionman]

I can see the benefit of both approaches.

if you use large max time steps, you guarantee that calculations can finish in the alotted time, so no nominal slowdown. At the expense of accuracy. The calculations usually don't care what the time step is, they take the same time to complete either way.

If you use small max steps, you favor accuracy, at the risk of running in slow motion. This has advantages because mathematical models are only good as long as certain results remain within acceptable bounds. Large time steps risks large displacements, that is situations where the physics is modeled by simple rules but the results leave the system in a configuration where other, more complicated forces would (in reality) come into play to stabilize it. Non-linear response can be especially bad here, if implemented poorly.

So you end up in configurations with excessive internal forces, which overreact on the system, so the NEXT frame is also out of bounds, which overreacts (or the opposite, where it doesn't react enough and the next frame is still out of bounds) and…

…and it snowballs and the Kraken eats your ship. A small time step causes the next calculation to occur while the results are still in the expected range, hopefully before things get out of control. It'll run more slowly, but hopefully with less world-destroying bad.

It's also why you're warned to avoid high physics timewarp - that forces the game to use larger time steps, not just do it when it has to.

Edited February 5, 2016 by pincushionman

[Moesly_Armlis]

That makes perfect sense to me.

When moving a kerbal around a station it would be faster frames and less CPU intensive to use the value of 0.12 in contrast when landing a high part count vessel the advantage would be the value of 0.03 for max delta time per frame.

 

I currently use 0.08 and not had any issues with kraken attacks and when walking a kerbal around the action is rarely in slow motion.

Edited February 5, 2016 by MoeslyArmlis

[NathanKell]

@MoeslyArmlis I am saying it has literally nothing to do with the game setting. Because the game setting does not, and never will, affect physics timestep--that would be horrific.

[Moesly_Armlis]

@NathanKell Are we discussing the same thing because your last statement has confounded me.

Max Physics Delta Time per Frame setting in the configuration.

[PnDB]

35 minutes ago, MoeslyArmlis said:

Are you saying that is not how to approximate the value for π?

Is that what you were doing?  I think everyone was distracted by your legs in the last photo. 

[NathanKell]

@MoeslyArmlis yes, we are. Physics updates run on a fixed game-time timestep (20ms), or, if using physics warp, 2x, 3x, or 4x that value. Visual frames run on a variable timestep, based on how much has to be done. As the time between visual frames grows longer, more and more physics frames are run. That setting effectively determines the number of physics frames that can be run per visual frame before the visual frame is rendered and you go on to preparation for the next visual frame.

The accuracy of the underlying physics does not change at all. What changes is how often there's a visual snapshot of the physical reality.

 

EDIT: Example.

Say each physics frame takes 5ms to run. That means, for a (visual) framerate of 50FPS, you have 15ms per frame to spend on other things (including rendering the frame). Now, for a visual framerate of 25FPS, you need to run 2 physics frames per visual frame, and let's say now (slower computer) each takes 7ms to run. That leaves you with 26ms to render the visual frame and do whatever else needs doing. With the slider all the way on the right (EDIT: Left, in modern versions of KSP), that's saying you can have a maximum of 1.5 (0.03s = 20ms x1.5) physics frames per visual frame, which means the game can no longer run in realtime; it has to slow physics (game time) down so it can maintain <= 30ms of ingame time per visual frame.

necro-edit: see this excellent modern recap by @damerell

 

Edited June 12, 2022 by NathanKell

[NathanKell]

>.> QA format. My response just got an upvote and is now out of sequence.

[Moesly_Armlis]

14 minutes ago, NathanKell said:

@MoeslyArmlis yes, we are. Physics updates run on a fixed game-time timestep (20ms), or, if using physics warp, 2x, 3x, or 4x that value. Visual frames run on a variable timestep, based on how much has to be done. As the time between visual frames grows longer, more and more physics frames are run. That setting effectively determines the number of physics frames that can be run per visual frame before the visual frame is rendered and you go on to preparation for the next visual frame.

The accuracy of the underlying physics does not change at all. What changes is how often there's a visual snapshot of the physical reality.

From my experiments altering the Max Physics Delta Time per Frame did not seem to affect a vessels structural integrity (no kraken attack).  These result should be expected because "the underlying physics does not change at all.".

Then the Max Physics Delta Time per Frame should be set to the maximum of 0.12 for slower running GPUs without fear of kraken attacks.

Thanks for taking time to explain this.

 

p.s.

 I think everyone was distracted by your legs in the last photo. 

Plot Twist: Those are not my legs.

Edited February 5, 2016 by MoeslyArmlis

[kunok]

8 minutes ago, NathanKell said:

@MoeslyArmlis yes, we are. Physics updates run on a fixed game-time timestep (20ms), or, if using physics warp, 2x, 3x, or 4x that value. Visual frames run on a variable timestep, based on how much has to be done. As the time between visual frames grows longer, more and more physics frames are run. That setting effectively determines the number of physics frames that can be run per visual frame before the visual frame is rendered and you go on to preparation for the next visual frame.

The accuracy of the underlying physics does not change at all. What changes is how often there's a visual snapshot of the physical reality.

 

EDIT: Example.

Say each physics frame takes 5ms to run. That means, for a (visual) framerate of 50FPS, you have 15ms per frame to spend on other things (including rendering the frame). Now, for a visual framerate of 25FPS, you need to run 2 physics frames per visual frame, and let's say now (slower computer) each takes 7ms to run. That leaves you with 26ms to render the visual frame and do whatever else needs doing. With the slider all the way on the right, that's saying you can have a maximum of 1.5 (0.03s = 20ms x1.5) physics frames per visual frame, which means the game can no longer run in realtime; it has to slow physics (game time) down so it can maintain <= 30ms of ingame time per visual frame.

I think an in-game short explanation will be good. At least something like: lowering this could improve your fps, but not the general speed of the game

[NathanKell]

@MoeslyArmlis sure! That means it will look visually choppy, but your gametime will be closest to realitme. Moving the slider to the right means things will "look" smoother, at the cost of things happening slower (game time becomes slower than realtime).

 

Of course, all this is assuming I understand the Unity docs right.

[pincushionman]

15 hours ago, NathanKell said:

 …Of course, all this is assuming I understand the Unity docs right.

Well, I for one am going to have to defer to you here, given that you get to work with the engine internals and all!

[Stone Blue]

16 hours ago, NathanKell said:

@MoeslyArmlis yes, we are. Physics updates run on a fixed game-time timestep (20ms), or, if using physics warp, 2x, 3x, or 4x that value. Visual frames run on a variable timestep, based on how much has to be done. As the time between visual frames grows longer, more and more physics frames are run. That setting effectively determines the number of physics frames that can be run per visual frame before the visual frame is rendered and you go on to preparation for the next visual frame.

The accuracy of the underlying physics does not change at all. What changes is how often there's a visual snapshot of the physical reality.

 

EDIT: Example.

Say each physics frame takes 5ms to run. That means, for a (visual) framerate of 50FPS, you have 15ms per frame to spend on other things (including rendering the frame). Now, for a visual framerate of 25FPS, you need to run 2 physics frames per visual frame, and let's say now (slower computer) each takes 7ms to run. That leaves you with 26ms to render the visual frame and do whatever else needs doing. With the slider all the way on the right, that's saying you can have a maximum of 1.5 (0.03s = 20ms x1.5) physics frames per visual frame, which means the game can no longer run in realtime; it has to slow physics (game time) down so it can maintain <= 30ms of ingame time per visual frame.

I THINK, I got the basic premise, but reading this sure made my head hurt for quite awhile... LOL

[SpaceNomad]

I suggest installing KerboKatz FPSViewer and KerboKatz PhysicalTimeRatioViewer (see here) for experimenting with this setting. They let you see and edit the parameters ingame.

For example with maximumDeltaTime of 0.02s I currently get 24 FPS and a physical time ratio of about 50% (which means, that per second real time only 0.5s of ingame time elapse, so slow-motion ).

With maximumDeltaTime of 0.08s I get about 13 FPS but my physical time ratio is about 100% (so I get real-time instead of slow-motion, but the display is more stuttery due to lower FPS).

[numerobis]

On February 5, 2016 at 5:45 PM, NathanKell said:

Of course, all this is assuming I understand the Unity docs right.

Every time I read the Time.maximumDeltaTime docs I come to the opposite conclusion of the previous time I read the page. Some of the Unity docs really need some love, and that's one of them! The key problem is there are two or three notions of time, and that document uses the same word for all three.

One thing I've noticed is that you *always* get a FixedUpdate before an Update. If, say, you want to run a physics frame every 20ms and a graphics frame every 30ms, that means you get this sequence:

Time = 20ms: FixedUpdate with fixedDeltaTime = 20ms

Time = 30ms: FixedUpdate with fixedDeltaTime = 10ms

Time = 30ms: Update with deltaTime = 30ms

So if your graphics frame isn't an even multiple of your physics frame, you get extra physics frames, aka CPU bogs you down.

[batman78781]

On 2/5/2016 at 6:19 AM, panzer1b said:

(its not like KSP comes with a handy FPS measuring system that i can do tests with)

If the alt-f12 FPS takes up too much space, and you run KSP on steam, there is a setting in steam to let you see FPS in any corner you like of the game. It matches up nicely with the debug menu, so you can pick the one that is most visually appealing to you.

[HMIC]

Messed up, this  is the wrong thread, had to edit this out and place it in the right place. SORRY!!

Edited February 11, 2016 by HMIC
Wrong Section and thread .. changing

[Skylar']

my whole life was i lie until this... From 130parts > 6fps to 15 playble fps...  seems like put the scale in to left side not always mean perforance...  

[AlextheBodacious]

so... I should move it to the left if I want my slow computer to be closer to real time? I don't care about FPS, as long as 1 second of game is 1 second of real life, AKA green time (on the MET clock)

[flart]

So, to summarize: 

Max physics delta-time per frame slider to the right (0.12):
game_time is closer to real_time (less slowdown aka the clock is "more green"), but in the cost of visual FPS and stability (less FPS, more chance for kraken), 

Max physics delta-time per frame slider to the left (0.03):
max out stability and visual FPS (more FPS, less chance for kraken), but in the cost of game_time/real_time ratio 
(more slowdown aka the clock is "more red" aka 1 game second will last more (2,3,4...etc) real seconds)

Correct?

 

UPD.

Also, FlightSceneLoadKraken bugfix in the KSPCommunityFixes makes Max physics delta-time per frame  temporaly low on the LoadScene, that makes game a little bit more stable even with the large Max physics delta-time per frame

 

Edited November 14, 2021 by flart