FPS and Physics Timesteps

[Claw]

5 hours ago, Darren9 said:

The physics step (and therefore physics frame & physics FPS)

I hesitate to say "physics FPS" because I don't want to confuse the difference between a physics calculation frame (where physics is occurring) and a gameplay frame (where input is taken and the graphics are built). I've been using FPS to refer to the gameplay frames, and not about the physics frames (which I've measured in Seconds / UT).

Yes, any gameplay FPS above 50 is "wasted" in the sense that there will be some frames where no physics changes have happened. In that case, as you say, nothing moves for that gameplay frame.

Physics updating, however, is different than the visuals updating. The user may have (for example) panned the screen camera around. In that case, the picture does update even though the physics might not have updated. Higher FPS gives the user a smoother play experience, but does not always give a good indication of physics performance.

Also, the physics is fixed to a maximum of 50 physics frames per second. The physics timestep is fixed at 20ms, but it may take longer than 20ms to actually calculate the physics change. In which case, gameplay time (UT) runs slower than real time.

[Draradech]

I've read this thread completely and still haven't understood this fully. I hope my question make some sense to you:

1) Can a physics step be interrupted to draw a gameplay frame? Does it make a difference if it is the first physics step in this gameplay frame or 2nd - nth (assuming < 50 fps here)?

2) Is the allowed time quota for physics steps reset per gameplay frame, or is it something that can be over- or underused and transferred to the next gameplay frame? (only makes sense if physics steps are non-interruptible) Another way to formulate this question is: Can the number of physics steps per gameplay frame only be a whole number? (Is 0.03 / 0.02 = 1, so 1 physics frame per gameplay frame or 1.5, so alternating between one and two physics frames per gameplay frame)

(scratched number 3 - reread the top post, question didn't make sense)

Edited March 3, 2016 by Draradech

[Rocket In My Pocket]

Since 0.03 is the lowest setting allowed by the game, can you shed some light on why?

Also, would you see any further differences by manually editing the .cfg file down to 0.01?

What could happen at really extreme values? Like 0.0000000000001? Or 100.0? Wold the game just ignore them and default to something reasonable?

[Claw]

1 hour ago, Rocket In My Pocket said:

Since 0.03 is the lowest setting allowed by the game, can you shed some light on why?

I don't know why 0.03 is the lowest setting, but the lowest setting practical setting is 0.02. There's no reason to go below this, because the game is already fixed at a physics timestep of 0.02. So the game would calculate physics and check to see that 0.02 (or some smaller amount of time) has passed. So having 0.01 or 0.00000001 wouldn't matter because at least 0.02 seconds have passed.

A setting of 0.02 (or less) basically means you are telling KSP you want to see a gameplay frame after each physics frame no matter what. So if the game is running really slowly, you'll still see a gameplay frame for every physics frame, unlike a setting of 0.04 where you would see a gameplay frame per every 2 physics frames. Or a setting of 0.12 where you'd see one gameplay frame for every 6 physics frames.

[Claw]

2 hours ago, Draradech said:

1) Can a physics step be interrupted to draw a gameplay frame?

No, it can't, nor can a physics frame interrupt a gameplay frame. And while the game tracks how much time has passed, it generally doesn't matter which frame it's on except for some specific cases like physics hold (where physics onset is delayed until elements of the game are loaded).

 

2 hours ago, Draradech said:

Is the allowed time quota for physics steps reset per gameplay frame, or is it something that can be over- or underused and transferred to the next gameplay frame?

That's a good question. Off the top of my head I believe it does carry over fractional numbers...but really I would need to go check to see if the game does indeed carry over. So don't quote me on that one just yet.

[ArgenTum]

On 2016-02-21 at 3:15 PM, Claw said:

The physics timestep is fixed at 20 milliseconds (ms). So, if I'm doing the math right, that means that there are 50 physics frames per second.

Ok. So lets see if I finally get this. If the slider is low (0,04) I probably get more FPS, but also more real-world seconds pass per in game second, resulting in the game running slower. If the slider is to the left, ie higher number (0,12) I will get fewer FPS, with larger input lag, but with probably faster running game, where 1 second in game continues to be 1 second in the real world. So for me, who don't want to spend forever in the atmosphere, I probably should move the slider to the left, and accept a drop in FPS (as long as the rocket doesn't become uncontrollable due to larger input lag). So those who uses mechjeb to launch very large rockets and gets a slideshow as it is, would probably save time by increasing time-delta? 

One actual question: Why exactly at 20 milliseconds? Because that's how Unity does it, or because Squad has chosen 20 milliseconds? In the latter case, could it theoretically (or practically) be possible to change to every for example 25 milliseconds and thus gain 20% performance?

Edited March 3, 2016 by ArgenTum
confused left and right.

[suicidejunkie]

On Thursday, March 03, 2016 at 10:05 AM, ArgenTum said:

One actual question: Why exactly at 20 milliseconds? Because that's how Unity does it, or because Squad has chosen 20 milliseconds? In the latter case, could it theoretically (or practically) be possible to change to every for example 25 milliseconds and thus gain 20% performance?

If you hit '.' in atmosphere, you'll get physics warp of 2x.   What you're requesting is exactly the same, but with the number set to 1.25 instead of 2.

I'm not sure about fractions between 1 and 2, but something along the lines of Better Time Warp mod would be a good start.

[Renegrade]

Thanks Claw - I've always wondered what that setting was for (and distrusted prior explanations).

Just an interesting aside - I believe most FPSes use what I call a "dynamic time delta" (this won't be standard jargon, as my background is business/finance/web/big data/uhhh adult entertainment programming, not game.  Game programming is a hobby for me, I made up my own jargon, and don't use established engines.  I should perhaps say that game ENGINE programming is my hobby), where they actually measure the time since the last frame when calculating how far to move players, projectiles, and NPCs.  So generally, even on slow systems, things progress at the proper rate per real time (a character running along at 8m/s makes 32m in 4s even at 0.25 fps, they instantly jump to the 32m mark heh).  This sometimes causes some pretty serious malfunctions, as time in a computer is NOT guaranteed to advance, which can sometimes lead to a zero or negative delta-t, which can mess things up pretty badly if the programmer isn't guarding against invalid values.   (In case anybody wants to know why time would run backwards - time sync is sometimes done with bumps (ntpdate -b) instead of skews..and always done with bumps in Windows)

My own systems usually use a "fixed delta time" which is very similar to the KSP system, only it scales to the current display mode frequency (on my desktop my default physics step is about 16ms).  All performance metrics for ships and such are expressed in units per second, and I recalculate from that per-sec into dedicated per-frame variables every time the display mode changes (which is once after startup, and once any time the user switches display modes, which in a typical session is between 0 and 1 times, heavily favoring 0 heh).  Since my designs are usually graphics bound instead of physics bound, I simply drop graphic frames to catch the physics up to real time constantly.

I believe Space Engineers does something similar to KSP as well, as it has a ratio that expresses the current gap between real time and physics updates.

TL;DR: I have hobbies. Sorry for rambling on

[Claw]

On 3/3/2016 at 10:05 AM, ArgenTum said:

One actual question: Why exactly at 20 milliseconds? Because that's how Unity does it, or because Squad has chosen 20 milliseconds?  In the latter case, could it theoretically (or practically) be possible to change to every for example 25 milliseconds and thus gain 20% performance?

I don't know specifically why (that was all decided well before I discovered the game). It is possible to increase the step size (as is done when using physical warp). It really depends on how you define performance (which is sort of what the original post is getting at). But in some ways, yes...Increasing the size of the timestep can increase performance because you have to do less calculations per second of game time. However, that also increases the force on the vessel parts, joints, etc. So increasing the physics time step is not without it's drawbacks. If you've ever had an airplane fold in half while using phys warp, then you'll know what I'm talking about.

 

4 hours ago, Renegrade said:

I believe most FPSes use what I call a "dynamic time delta"

Yeah. A lot of games (at least historically) tied time passage to the computer's ability to produce graphical frames. So if it took longer to build a graphics frame, the gameplay still moved along at some rate. That's why "moar FPS is better." But since KSP is physics driven, moar FPS isn't always a pure measure of performance.

[Renegrade]

1 hour ago, Claw said:

Yeah. A lot of games (at least historically) tied time passage to the computer's ability to produce graphical frames. So if it took longer to build a graphics frame, the gameplay still moved along at some rate. That's why "moar FPS is better." But since KSP is physics driven, moar FPS isn't always a pure measure of performance.

Well, moar FPS is also moar smoother, but yeah, in my, or KSP's, or Space Engineer's case, not necessarily the best measure   Actually, for my own benchmarking purposes, I include little timers on the screen indicating how long a 'compute' (physics) and 'render' (graphics) frame takes, so I can know what's lagging and by how much

I have to admit I'm a little buzzed to find out that KSP uses a system not entirely unlike the one I devised. Whee!

[Gasofidas]

Thanks a lot for explaining this, let me rephrase it in my own words to see if I got to understand it (while CPU capped in a high part ship):

•  Graphics (FPS) require both GPU and CPU time, and physics calculations only CPU time.
•  Physics timestep sets how often the graphics (FPS) is updated per each physics calculation.

1.        the lower it is set (0.02), the more often graphics are updated, so the smoother it looks but takes longer to complete.
2.        the higher it is set (0.12), less graphical updates, the faster it completes but feels choppy.

 

Edited March 31, 2016 by Gasofidas

[zarakon]

One of my favorite mods has always been DynamicWarp, which adds the ability to speed up the physics step rate instead of the size.  That means more CPU load, but none of the accuracy problems that come with the normal physics warp.  It's also nice that it's able to stack with the existing warp modes to achieve things like 16x physics warp and 800000x rails warp.  Also includes the option to slow down the step rate to see things in accurate slow motion

It would be nice for that to be a built-in mode

Edited March 31, 2016 by zarakon

[Claw]

6 hours ago, Gasofidas said:

•        the lower it is set (0.02), the more often graphics are updated, so the smoother it looks but takes longer to complete.
•        the higher it is set (0.12), less graphical updates, the faster it completes but feels choppy.

Sort of, but not exactly. This is one of the misconceptions that can be hard to visualize.

A lower setting (0.02) means that the game is forced to draw a graphics frame for every physics frame that it completes (because physics also runs at 0.02). So it's not that it will be smoother, it just means you will see every physics frame. In general, as the game starts to have trouble keeping up with "real-time" physics calculations, the game will start to get more slide-show like sooner.

With a higher setting (0.12), you get less graphical updates only when the game starts to have a hard time keeping up with "real-time" physics calculations. In that case, you're skipping the CPU/GPU rendering of graphics, and diverting that processing power to help keep physics as fast as possible. So in that case, the game will still get a little bit of a slide show, but the physics simulation will be running at a faster rate than if it was set to 0.02. So you'll visually see maybe only every 6th physics frame, but the physics might still running real time.

I'm not sure if that made it any clearer. 0.12 might feel more choppy, but it would be running at a faster graphics frame rate. It's also important to note, this is all assuming that KSP isn't keeping up with physics calculations. When it is keeping up, the ratio doesn't come into play.

 

5 hours ago, zarakon said:

the ability to speed up the physics step rate instead of the size

That's an interesting concept. Would work well for instances when KSP is capable of doing the physics faster than 0.02s (i.e. small ships).

[FullMetalMachinist]

28 minutes ago, Claw said:

0.12 might feel more choppy, but it would be running at a faster graphics frame rate.

'Scuse me Mr. Claw sir, but should that be "0.12 might feel more choppy, but it will be running at a faster physics frame rate"? If not, sorry for the confusion. 

[RA3236]

Umm, so how come my setup would be okayish, if my graphics card is not up to standard?

I think that my graphics is my limiting factor on my laptop to run KSP, and I found no noticable difference from VSR and DTL 1.0.5 to unmodded 1.1. My graphics are a ATI Radeon HD2600 at 256mb (someone's going to yell at me for not getting a new computer), so how does graphics decrease FPS and the UT time to real time?

[Claw]

9 hours ago, RA3236 said:

Umm, so how come my setup would be okayish, if my graphics card is not up to standard?

I'm not sure I understand this question.

But to your second question...If it takes longer for the graphics card to generate the graphics frame, there will be less time available to do physics calculations. So it's still the same considerations, in that if you ask the graphics card to do less drawing, there will be more time available for the physics calculations.

[RA3236]

3 hours ago, Claw said:

I'm not sure I understand this question.

But to your second question...If it takes longer for the graphics card to generate the graphics frame, there will be less time available to do physics calculations. So it's still the same considerations, in that if you ask the graphics card to do less drawing, there will be more time available for the physics calculations.

Thanks. Bout that question: auto correct did it. So replace wasn't with was and that is the question. But yeah, I get you, I am lucky that you SQUAD people have had the curtesy of adding a "Fastest" rendering mode to KSP. I cannot play it on Fast rendering mode.

[Wjolcz]

I have a question about KSP's performance over time.

So whenever I launch a fresh install of the game the FPS is about 60. Then after an exit and another game launch it drops a few frames down. Then with every launch-exit-launch step the Delta-Time hits and I launch my vessels in slo-mo. I speed up the simulation and the game runs in real time, but the FPS is about 25-30.

What's with that? Does it have something to do with cache getting cluttered?