Options Settings vs. In-Game performace

[Diazo]

edit: Anyone know how I shrink the images to 75% size?

Alright, in response to seeing confusion about just what performance people are getting in the game, I went ahead and ran some benchmarks.

This post is in 3 sections, the Graphics Settings to start, the Delta-Time for physics setting in the middle and my testing process at the end.

Note that at no point did I see the game clock go red although it was a solid yellow for the first part of the flight consistently.

All graphs are my FPS up the Y-axis with real world time in seconds across the bottom on the X-axis. V-sync is off with 120 Max FPS set in KSP options.

Graphics Settings

First, my results.

My test runs lasted for exactly 5 minutes, 30 seconds (or 330 seconds) according to the in-game clock, so that is where each run ends. This can be seen as the Low (Yellow) setting not running to the right edge of the graph, meaning it took a few seconds shorter in real world time for that launch to reach the 5:30 mark in-game.

Also note that the graphics settings do not really matter while the physics engine part of the game is overloaded. All 3 settings have the same FPS until about the 100 second mark, which is when several stages have been dropped and the part count is down significantly.

After that point however, the graphics settings do matter as the physics engine, while still struggling, is not overloaded with part count like it was at launch.

It looks to me like the physics calculations are pretty brute force and their is no real way to get better performance with high part count ships on the user end of things short of changing the computer KSP is running on. (Both Operating System and Hardware tweaks apply here.)

DeltaTime for physics was set at 0.1 for these test. On the Low No Sound run only, the sound normalization was disabled and all sound volumes set to 0%.

High Settings:

Medium Settings:

Low Settings:

Oops, I lost a screen shot. Render Quality was for sure Lowest and Texture Quality was at 1/8th for sure on the Low Settings run. Low was as low as everything could go.

Delta-Time Physics

The "Max. Physics Deta-Time per Frame" setting is big enough I ran some test dedicated to it.

Now, this setting is where we can really affect frame-rate, it is not without trade-offs however.

What this setting actually does is tell the game how long you are willing to allow the physics engine to claim all it's processing power before it interrupts the physics to draw another frame.

The default setting of 0.1 (a frame every tenth of a second) tells the game to try a maintain a minimum FPS of 10.

It does an okay job of this, a setting of 0.03 (33 fps) results in 20 fps in reality and 0.1 (10 fps) results in a fps of 7 or 8. This means that as this setting goes higher, it has less effect. If you are going to set it to 0.5 (2 fps) you might as well go all the way to 1.0 (1fps). This is really a personal preference, how choppy a game can you put up with to launch that high parts-count ship?

The trade off is in how slow the game runs. As the physics engine does not drop calculations, it slows game time down as much as it needs.

On the chart above, a 330 second flight (as per the in-game clock) took only 338 seconds at DeltaTime 1.0, but took 402 seconds at DeltaTime 0.03.

This time loss is pretty much in the first 150-160 seconds of flight, so an extra 72 seconds (402 - 330) is adding almost 50% to your flight time by running a DeltaTime of 0.03 instead of 1.0

The trade off being a minimum framerate of about 20 as opposed to a frame rate of 1. You'll have to find your own sweet spot on this.

Test Method

Fresh Steam install (nuked the folders and re-downloaded it). Grabbed the 600 Part CPU Test ships from here and loaded it directly on the pad with 3 kerbals on board. Used FRAPS as noted in the thread to record the FPS.

Tilt the view up until the Fuel Tank Tower(?) is just touching the left most kerbals portrait (fuel tank bottom right to portrait top left). This should remove the ground from view.

SAS on, 100% Throttle. Hit Space to start the flight, this is the 0 second mark for both the in flight clock and for the FPS charts. I then hit each stage at the same second for each flight. Flight just went straight up on SAS, I did not issue any directional inputs. Stop the FPS recording at the 330 second mark in-game clock (which is during stage 5).

Change the settings needed and the close and re-open the game. The first tests when I did not close the game showed a 5-10% worse performance on subsequent flights when I did not close the game out completely to free up all the memory.

So, what does it all mean?

Well, this was an interesting experiment, but I'm not sure I actually proved anything. The physics engine is still the major limitation on high parts-count ships and I was not able to affect this with any of the settings found in the game.

I'll throw this out there for other people to see and I believe it is valid data worth adding to the community's knowledge base, so have a look and we'll go from there.

D.

Edited September 7, 2013 by Diazo

[pa1983]

I was under the impression that the physic engine dot "drop" calculations. I mean you must finish it or it just wont make sense. I was under the impression physics works similar to frames where frame rate is a resolution. Lower the Physics Delta and fewer irritations (calculating the interactions of the parts, stress, collisions etc) are made etch second meaning theres less resolution on the physics part of things.

If physics where not completed for etch physics frame if thats how it works odd things would happen I would assume.

I personally cant see any difference in the games behavior (bugs etc) with 0.1 or 0.01. Yes one can set 0.01 manually in the settings.cfg and I have used that for the past 6 months. Runs a lot faster but so fare no bugs or odd things that would not happen with 0.1 either.

I realy dont see the point of using 0.1 or even higher. Physics Delta seems to be the least used but most effective option to gain performance.

i dont know what CPU your running but a stock i7 3770 or a i7 3930K @ 4Ghz and the difference with 1100-1600 parts is still frames and super low real time VS playable frame rate (Still slow tough) and acceptable real time preformance. There is also the question of Real time rendering not just frame rate and the game tends to run a lot slower with high Delta Physics when it comes to real time with many parts.

EDIT: you should also write out what the Axis on your graph is, fps, time, parts etc so we dont have to assume. Especially if where not native English speaking.

Edited September 7, 2013 by pa1983

[DMagic]

Can you send me the log file for your 0.03 second physics delta time run and your CPU specs? I can add your results to my database.

It's not too surprising that you don't see much change at different settings. Except for a few options, terrain (especially the ocean terrain settings), and maybe really high light counts, or AA, KSP isn't really GPU limited. Most any midrange card can handle max, or almost max settings reasonably well.

Also, delta-time affects game-time, but it can cause physics errors if you move the slider too far left (lowering it below 0.03 in the settings.cfg can also cause issues). I think it's something like turning on physics warp; the game can't really keep so weird things can happen.

And I'm glad you noticed that performance seems to drop on subsequent runs during the same session of KSP. I'm not sure if this only happens with high part-count rockets or if it happens all of the time, but I've noticed it too and I should add that to my thread.

[pa1983]

Using 1-4x time warps seems to almost reset Physics Delta requiring a restart or the game will crawl to a halt and show still frames. Tough not sure its related to altering the delta physics becuse I didnt have that problem with 0.18.2 or older running Physics Delta at 0.01. I never use 1-4x warp for that reason. had that problem ever since the switch to unity 4.

I can run my 1100-1200 spaceplane on a stock i7 3770 with the integrated HD4000 graphics on most graphic settings on the lowest and some on medium and 1366x768 and its as fast as my i7 3930K and GTX570 so if you dont care about graphics HD4000 will do fine.

[Diazo]

@pa1983: Graph Axis added. Also, I assume that when the game-clock goes red is when the physics engine drops calculations. I never saw that however, just yellow at launch start when under heavy load.

@Dmagic: I'm intending to do that tomorrow, I'm currently messing around with overclock settings at the moment and have not settled on what I'm going to use.

Also, on the multiple launches thing, sometimes when I would "Revert to launch" the physics engine would throw a fit and the rocket would collapse as soon as physics kicked in before I could issue any commands. I'm assuming it is part of the memory not totally refreshing until you exit the game completely.

I'm probably going to try leaving physics delta at 0.2 for the rest of the day and see how that goes. If I'm right about how physics delta works that should leave the maximum time possible for physics while guaranteeing me at least 5 fps which I'm thinking would be a controllable ascent (experimentation required here.)

I did do a search, but I did not find a developer comment on how physics delta actually works.

D.

[pa1983]

Restart have not worked well for me in some versions. Better go back to SPH/VAB and launch from there works fine.

Never seen it go red either so.

[sagittary]

To clarify on physics without going into too much game engine details (or I'll try not to)...

There are two ways physics can be handled - a fixed time step or a variable one. In the latter, the time between frames is used as a 'step' for each physics calculation (how far did I move in the time it took to render the last frame). In the former, that step is constant (how far did I move in 0.01 seconds); this also means that between any two given frames, zero, one, two, maybe more physics time steps can occur.

Regardless of method, any time a physics update occurs, the game needs to know how much time needs to be 'caught up' so that physics match what is being rendered (time accumulates between physics steps and then is 'used' until there is less time than a time step). The catch is that if a long time occurs between steps, the work that is needed to be performed may be a very large amount - which in turn may mean that even more time is spent updating and thus delaying the next step.

The behavior at this point and what Max Time Step means changes at this point.

In a variable time step, if we don't do something, this may mean that delta-time (like delta-v but with time), may be very big. Dramatic changes in time step or large chunks of time can screw with physics. You move a lot more 1 second than you do in 1/100th of a second. This in term can mess up physics calculations since you're losing precision; if your acceleration changes over time, your speed if you simulate a full 1 second will be very different than 0.01 second since that acceleration can only be updated at the step. To prevent this, we can set a Max Time Step such that no matter how long it's been since the last update, we never simulate more than that step.

In a fixed time step, what will happen is that there will reach a point where so much work/so many time steps have to occur to catch up that it actually takes longer to do that work than we have available in that frame. For instance, if we run at 30 frames per second, this means that any and everything that we want to do for that frame needs to, in total, take less than 0.03 (repeating) seconds or the next frame will be delayed. So say our fixed time step is 0.01 secs. Delta-t for frame 1 is 0.03ms, so we run at least 1 time step. But say we have a lot of calculations or there is slow down elsewhere in the system and our Delta-t is 0.1 second. To catch up, we might need 10 steps. The problem is, doing those 10 steps might very well take more than 0.03 seconds... so we slow down even more. To combat this, we can limit ourselves to simulating a certain number of steps (a certain amount of time).

Bringing it back to the topic, changing the max physics time step won't actually produce any difference unless and until there's actually a large amount of slow down to begin with. Also, given the physics dependent nature of the game, it's highly unlikely that the game drops physics calculations - it more than likely caps calculations and drops frames instead. From when I goofed around with it a while ago, the larger the max time step, the bigger chunks of time the game will attempt to simulate when slow down begins to happen. This will result in crazy physics due to errors. The smaller the time step, the more physics will remain accurate but at the cost of frames.

As an example of where physics become crazy (and the math on this is probably way off but the point is illustrated), imagine you're starting from a stand still and slowly increasing your throttle from 0 to 100% (from say, 0 meters per second to 10 MPS) over 1 second. If your physics step is every 1 second, your position at 1 second is 0 (starting off, you have 0 acceleration so you didn't move) while at 2 seconds, you've moved 10 MPS. However, if we simulate smaller chunks.... at 0, acceleration is 0 so we move zero. At 0.5, our acceleration is 5mps, but we've moved 0. At 1s, our acceleration is 10 mps, but since we already had acceleration/velocity going into this step, so we move 5 meters and are at position 5. You can see where, as we increase the step, we get a better representation of actual physics.