Developer Insights #18: Graphics of KSP2 Early Access

Hi Y’all,

I’m Mortoc, the new graphics programmer on the team. I wanted to take some time to chat about KSP2’s graphics and performance – where we are today and what our process is and what the team’s goals are.

As many of you have noticed, KSP2’s performance isn’t amazing at the start of Early Access. In a game as complex as KSP2, there are a dizzying number of areas that we could spend our efforts on and the feedback we’re receiving is invaluable for us to focus our time on the issues that affect the players the most.

There are different reasons that the framerate can suffer. If the CPU is asked to do too much during simulation or if the CPU is asked to send too much data to the GPU in an organized fashion, it can make the framerate drop without maxing out the GPU. In most cases the performance in KSP2 is bottlenecked by the GPU, and since I'm a graphics engineer, that's what we're going to investigate in this article. Other engineers are working hard on CPU-facing improvements that you'll see reflected in upcoming updates.

Deep Dive Warning: Numbers Ahead

Before we dig into the numbers, let’s start with a primer on what we’re looking for here. Game developers tend to think of framerate in terms of milliseconds rather than FPS because it’s easier to budget out your frame time that way. Converting from FPS to ms is simple, you just use the formula 1,000 / FPS = ms (for example: 100 FPS means it takes 10ms per frame, 1,000 / 100 = 10). This way we’re talking about how long a system takes to run directly. We want to measure how many milliseconds each system in the game takes in order to figure out which are taking too much time and dropping the framerate.

We use a tool called RenderDoc for our automated performance testing (among other tools). RenderDoc allows us to get the ground-truth timings for every single command sent to the GPU. Our tooling can then pull out the slowest GPU events for us to investigate.

The machine I’m using here for performance analysis is a laptop with i7-8650U CPU, Mobile Nvidia GTX 1060 6gb GPU and 16gb RAM. It has a slower GPU than our current min spec, so we’re not expecting it to make a playable framerate yet.

KSC Landing Screen – 11 FPS

In this scene, eight of the top ten worst-offenders are related to PQS+. PQS stands for Procedural Quad System and it’s the algorithm used to generate planet terrains. KSP2 uses a modified version of PQS from KSP1, generally referred to as PQS+ after all the modifications made to it for KSP2.

That table starts with a draw call to PQSRENDERTEMP, which emits 229,248 vertices. Each other draw call that uses that specific number is doing some work on the PQS mesh. The two draw calls not related to PQS in that table are the ones with a 6 in the name and are related to the cloud system. From this report we can see that the terrain clearly takes the most GPU time in this scene; 29.94ms in total.

Let’s try another vantage point.

LKO – Low Graphics – 8 FPS

As you travel away from any Celestial Body, we swap out the complex Local shader with a Scaled version that’s much more efficient. This scene is from Low Kerbin Orbit, but still close enough to the planet to be using the Local version of the shader. PQS+ is again 8 out of the top 10 worst calls (the line Dispatch(12, 240, 1) which is Draw Call #1 is from at the start of the frame when we kick off a compute shader to generate the terrain mesh). That first PQS+ call that took over 10ms is especially dirty.  Staying Grounded

Clearly the PQS System and related shaders are a big performance problem. Let’s talk about that, but first dig into some background. A core philosophy for the early part of KSP2’s EA cycle is to make sure “it still feels like a KSP game”.  This means that for each feature we build, we want to start with what KSP1 did and then build a similar system that improves on it.

Following that goal, the team started with the PQS design from KSP1 and added modern graphics features for KSP2’s PQS+. As development progressed on KSP2, more and more features were added to PQS+ to keep pushing the artistic envelope.

I might be biased, but from orbit, Kerbol’s planets look incredible. Our art team did a fantastic job. From the surface the game is still quite pretty, but the terrain itself just doesn’t have the consistent visual quality we want yet. While trying to build that ground up to our visual ambitions, we added more features than the previous PQS architecture can support. It wasn’t until the ramp up to EA that it became understood just how far past the limits of the tech we had reached.   Future Trajectory

OK, so, clearly there’s a problem, what are we going to do about it? A few things are being done simultaneously. First, we’re prioritizing performance optimizations for this system over the next couple of patches. Particularly for when graphics settings are “LOW”, we want this system to be eating far less GPU time. This takes two forms: one is pure engineering optimization that doesn’t affect final graphics, the other is to disable certain visual features when the graphics are set to “LOW” or “MEDIUM”. That first category, engineering-only fixes, was taken about as far as it could be with PQS+. Our short-term plans are currently focused on the 2nd category, turning off features that don’t provide enough bang for the buck.

Here's an example of an optimization that affects the visuals. Coming soon in a patch, we will be able to turn off the Anti-Tile system in the terrain. In a bunch of places, the effect is negligible, but you can see the Eve surface has a repetitive texture artifact without it. This visual polish comes at the cost of accessing each texture a few more times, putting strain on the memory bandwidth of the GPU. Disabling this effect can have a small-to-medium sized effect on the framerate, depending on the GPU in question.

Optimizations like that one are happening now and will arrive in the next few updates. The rest of this article deals with systems that are in progress, so we cannot make specific promises about timelines or features until further along in development. But here’s where we’re heading:

In the medium term, my first major project on this team is to design and build a next-generation terrain system – what we’re calling the CBT system (it uses a Concurrent Binary Tree data structure, but it could also stand for Celestial Body Terrain). PQS+ has served us well, but nowadays video cards are much more flexible and there are more modern approaches that will give us better results in terms of performance and visual quality. Exciting new earth-shaking architectures are possible. The next-gen CBT system will be the topic of a future dev blog which will contain a much more detailed look at what we’re building. While it’s too early to share any details, I will say that I’m excited about the artistic expressiveness, potential terrain variety, and performance of the CBT system.

Another area that will see a major shift in visual quality and performance is bringing the game up to Unity’s modern renderer, HDRP (read more about HDRP here if you’re curious, it rocks). The main benefits we get from HDRP are a more optimized render engine, which means faster framerates, and a more flexible shader model, which means more effective dev team efforts. It’ll also make it easier for visual mods to be built. As a sidenote, despite how much we love you modders, this change will definitely break most visual mods (sorry modders, sometimes we must hurt the ones we love).

These in-progress changes will allow us to build more scientifically grounded yet fantastical worlds for the Kerbals to explore for years to come.