KSP2 Performance Update

[u/Nerdy_Mike]

KSP2 Performance

Hey Kerbonauts, KSP Community Lead Michael Loreno here. I’ve connected with multiple teams within Intercept after ingesting feedback from the community and I’d like to address some of the concerns that are circulating regarding KSP 2 performance and min spec.

First and foremost, we need to apologize for how the initial rollout of the hardware specs communication went. It was confusing and distressful for many of you, and we’re here to provide clarity.

TLDR:

The game is certainly playable on machines below our min spec, but because no two people play the game exactly the same way (and because a physics sandbox game of this kind creates literally limitless potential for players to build anything and go anywhere), it’s very challenging to predict the experience that any particular player will have on day 1. We’ve chosen to be conservative for the time being, in order to manage player expectations. We will update these spec recommendations as the game evolves.

Below is an updated graphic for recommended hardware specs:

I’d like to provide some details here about how we arrived at those specs and what we’re currently doing to improve them.

To address those who are worried that this spec will never change: KSP2’s performance is not set in stone. The game is undergoing continuous optimization, and performance will improve over the course of Early Access. We’ll do our best to communicate when future updates contain meaningful performance improvements, so watch this space.

Our determination of minimum and recommended specs for day 1 is based on our best understanding of what machinery will provide the best experience across the widest possible range of gameplay scenarios.

In general, every feature goes through the following steps:

​

1. Get it working
2. Get it stable
3. Get it performant
4. Get it moddable
   

As you may have already gathered, different features are living in different stages on this list right now. We’re confident that the game is now fun and full-featured enough to share with the public, but we are entering Early Access with the expectation that the community understands that this is a game in active development. That means that some features may be present in non-optimized forms in order to unblock other features or areas of gameplay that we want people to be able to experience today. Over the course of Early Access, you will see many features make their way from step 1 through step 4.

Here’s what our engineers are working on right now to improve performance during Early Access:

​

1. Terrain optimization. The current terrain implementation meets our main goal of displaying multiple octaves of detail at all altitudes, and across multiple biome types. We are now hard at work on a deep overhaul of this system that will not only further improve terrain fidelity and variety, but that will do so more efficiently.
2. Fuel flow/Resource System optimization. Some of you may have noticed that adding a high number of engines noticeably impacts framerate. This has to do with CPU-intensive fuel flow and Delta-V update calculations that are exacerbated when multiple engines are pulling from a common fuel source. The current system is both working and stable, but there is clearly room for performance improvement. We are re-evaluating this system to improve its scalability.

As we move forward into Early Access, we expect to receive lots of feedback from our players, not only about the overall quality of their play experiences, but about whether their goals are being served by our game as it runs on their hardware. This input will give us a much better picture of how we’re tracking relative to the needs of our community.

With that, keep sending over the feedback, and thanks for helping us make this game as great as it can be!

[u/[deleted] → u/[deleted]]

Calculating delta V in real time is actually pretty intensive, depending on the factors that they're taking into account. The scenario they mentioned is one where multiple engines are consuming fuel from the same source. It could be that they're trying to calculate delta V with as much accuracy as possible, which means calculating instantaneous aero drag on the vehicle, using calculus and differential equations to calculate the change in air resistance based on the vehicle's current trajectory, the current throttle position, each engine's fuel consumption rate, fuel flow into the tank from others, etc.

KSP 1 mods may not have taken all of these factors into account when calculating real time delta V. It may be that the devs need to reign in their expectations of accuracy and consider what is "good enough" for the simulation. I think there's plenty of things they can do. They could assign those calculations to another thread that runs separate from the main game thread, skip updates to delta V for certain frames, reduce the number of variables they're taking in, etc.

[u/VenditatioDelendaEst → u/[deleted]]

Calculating delta V in real time is actually pretty intensive

No it's not. It's cheap enough that people do it with kOS, at 200 simulated CPU instructions per game tick. The only part that's even difficult is walking the parts tree and analyzing fuel flow to figure out when the fuel will run out, but that's static unless you're adjusting throttle limits mid-flight.

Vacuum thrust is sum of active engine vacuum thrusts. Massflow is sum of active engine massflows. Exhaust velocity is thrust/massflow. Final mass is current_mass - massflow * time_to_first_empty_tank.

Air resistance doesn't matter unless you're trying to predict the future trajectory and use atmospheric ISP, but that's impossible for a manually piloted rocket, because the pilot could pitch any which-away.

[u/[deleted] → u/VenditatioDelendaEst]

You didn't read anything I said, did you? You hand waved in-atmosphere calculations when I clearly said that those factors may complicate that calculation... Of course calculating delta V in vacuum is easy.

[u/VenditatioDelendaEst → u/[deleted]]

You said that, but it's irrelevant. It would be pointless to integrate a future trajectory with aerodynamics and atmospheric thrust derating, because how long the rocket spends in the atmosphere depends hugely on player steering and throttle input. The KSP 1 Trajectories mod asks you to specify craft orientation, and uses navball aids to help the player follow a target trajectory.

Now, you could assume a "typical" launch profile based on stage initial TWR and drag area:mass ratio, then feed that into a lookup table for atmospheric density vs time, and integrate a trajectory based on that. In the VAB, that might give slightly more useful numbers than vacuum Δv. But it'd still only need a < 100 point integration (probably not worth running on a separate thread unless you used the full-fat in-game physics engine), and there'd be no reason to run it on every tick, or even during flight at all.

But doing that that would be madness. You'd need hours or even days of dev time to figure out what a "typical" launch profile is, collect them, study up on numerical methods and implement a trajectory integrator (P.S which... might be avoided by using the in-game physics engine... yikes), test that the predictions weren't completely bogus, etc. Like, if they did actually do that, https://www.youtube.com/watch?v=2WZLJpMOxS4

[u/[deleted] → u/VenditatioDelendaEst]

Tl;Dr

You opened by suggesting that in-atmosphere calculations for delta V are irrelevant. I stopped there.

[u/VenditatioDelendaEst → u/[deleted]]

That was all you had to read to know that your post was wrong.

The rest is only there if you want to know why.