Jump to content

Developer Insights #18 - Graphics of Early Access KSP2


Intercept Games

Recommended Posts

  • KSP Team

image.png

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 

image.png

10 Slowest GPU Events  Draw #   Duration (ms) 
PQSRENDERTEMP\Draw(229248)  270 6.08
RenderDeferred.GBuffer\Draw(229248)  505 5.84
RenderDeferred.GBuffer\Draw(229248)  506 5.44
CloudCommandBuffer\DrawIndexed(6)  746 4.43
Shadows.RenderJob\Shadows.RenderJobDir\Draw(229248)  652 4.31
GenerateWaterDepthCommand\Draw(229248)  576 3.18
RenderDeferred.GBuffer\Draw(229248)  503 1.72
RenderDeferred.GBuffer\Draw(229248)  504 1.63
Draw(229248)  263 1.62
cloudsShadowCommandBuffer\DrawIndexed(6)  560 1.58

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 

image.png

10 Slowest GPU Events  Draw #   Duration (ms) 
PQSRENDERTEMP\Draw(92160)  237 10.44
RenderDeferred.GBuffer\Draw(92160)  301 4.06
RenderDeferred.GBuffer\Draw(92160)  302 3.14
RenderDeferred.GBuffer\Draw(92160)  304 2.34
Dispatch(12, 240, 1)  1 2.07
RenderDeferred.GBuffer\Draw(92160)  303 1.59
CopyResource(ObserverCubemapView_CubemapFinal, ObserverCubemapView_Temp)  92 0.60
CopyResource(CelestialBodyCubemapView_CubemapFinal, CelestialBodyCubemapView_Temp)  184 0.33
Camera.Render\PQSRENDER_DEFERRED_DECAL_MASK\Draw(92160)  230 0.24
Camera.Render\Draw(92160)  227 0.23

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. 


image.pngStaying 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.  

image.png

 

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.  

image.jpegHere'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.  

Link to comment
Share on other sites

Quote

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. 

Hell

Yes

Do it, my dude

And for the record the game looks amazing right now, Kerbin itself is incredible. I can't wait to see how it develops.

Edited by regex
Link to comment
Share on other sites

1 minute ago, whatsEJstandfor said:

I think, we've all been craving over the last two weeks.

Its a good read and I found it interesting. But no, if I'm honest I expected more information regarding the first patch the game desperately needs

Link to comment
Share on other sites

13 minutes ago, Intercept Games said:

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

Thanks Mortoc.  One thought that has occurred to me many times is user configurable on the fly lowering/raising of graphics quality based on simple rules.

Example, "if launching, dynamically adjust quality to keep frame rate over n".  Or "if night launch, skip most terrain rendering to achieve highest frame rate possible".  Even a way to completely disable terrain renders for that 30m time span while LKO docking and assembly of some huge, multi-module behemoth.

Edited by darthgently
Link to comment
Share on other sites

Thanks for explaining the current graphics system and its shortcomings in such an understandable way! the fact you guys know what needs to be improved and already have plans to make it happen is a great sign. Good luck with it, and kudos on the already absolutely stunning visuals in the game in this early version!

Link to comment
Share on other sites

13 minutes ago, Intercept Games said:

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. 

So this is going to replace PQS+ before 1.0 of KSP2? I am glad that KSP2 is still at a point that this kind of thing can be considered.

Link to comment
Share on other sites

I second that notion Anth. It feels rough that it took so long for the realizations that core things like this are not gonna be sustainable. But as long as there's a willingness to face what doesn't work, and if needed replace it, even if that's a tremendous amount of work, I'm glad to see it being treated for what it is!

Link to comment
Share on other sites

16 minutes ago, NoMrBond said:

What renderer is the game currently using?

I'm kind of shocked it's still using the legacy rendered... But beyond that, I remember how much flak I got on the forum for talking about modern HDRP Unity visuals. I invite newer users and players to read up on older discussions.

Thank you for this great dev diary! Telling it like it is goes a long way.

Edited by Vl3d
Link to comment
Share on other sites

Just now, Stoup said:

I second that notion Anth. It feels rough that it took so long for the realizations that core things like this are not gonna be sustainable. But as long as there's a willingness to face what doesn't work, and if needed replace it, even if that's a tremendous amount of work, I'm glad to see it being treated for what it is!

It might be that they wanted to get something they knew that worked from KSP1 so they could get development in all areas up and running.

Verses waiting for CBT to be developed before any other development areas could be started.

Link to comment
Share on other sites

Very interesting insight... even tho half of it goes over my head xD

I wonder, would it be possible, and have you guys considered adding DLSS in the future? It seems like it would be a very welcome addition to the game, and it would allow for some absolutely insane fidelity visual mods in the far future.

Link to comment
Share on other sites

6 minutes ago, Tazooka said:

Its a good read and I found it interesting. But no, if I'm honest I expected more information regarding the first patch the game desperately needs

I'm also eagerly waiting for the first patch! 

My interpretation for their silence is that the patch is currently in QA, and they don't want to give an exact date for when it'll be out of QA, because if you do that, there's a big risk that either it'll slip, or you'll have to release it in a worse state than you'd like. 

The project I work on is on a pretty regular 3-week cycle at this time, but even we can't predict exactly when a build is out of QA. Like, we're targeting next Wednesday to release the version currently in QA, but if something turns up before now and then (and it sometimes does! That's why we have QA, so they turn things up!) it might slip until Thursday or Friday, and if everything goes absolutely smoothly we might be able to release it already on Tuesday. We don't announce these dates to anyone because if they slip, people get annoyed and we have to Explain Things and that's no fun at all. 

Also: it took us a while to get to this point – we had to get the dev teams working together well, we had to get the deployment infrastructure set up, we had to get QA familiar with the project, we had to scale QA to match the dev teams' velocity, and so on. A year ago it took us about six weeks to push out a release, and the dates fluctuated a lot. We're continuously improving. We want to get to a 1-week cycle by the end of the year, and I think we know how to do it – we need to make some improvements to our infra and our process and then just lots of practice. Making games is a team sport – and like any team sport, the team has to train together to play together well, even if the individual players are really good at what they do!

Link to comment
Share on other sites

2 minutes ago, Anth12 said:

It might be that they wanted to get something they knew that worked from KSP1 so they could get development in all areas up and running.

Of course that's what happened. They used the prototyping tools as far as they could go.

Link to comment
Share on other sites

56 minutes ago, Intercept Games said:

This visual polish comes at the cost of accessing each texture a few more times, putting strain on the memory bandwidth of the GPU

Assuming the terrain shader is using Triplanar Mapping, this means that the samples for the anti-tile system increase by an additional factor of 3. KSP1's method of just scaling the texture based on the log of the camera distance from the terrain worked well enough, and might be a suitable replacement for low/medium graphics. That only required 2 samples * 3.

Also, since this is not mentioned often and articles about it are far and few... Triplanar mapping is superseeded by biplanar mapping which only requires 2 texture samples instead of 3, offering an immediate +50% performance at expense of a small additional amount of math.

https://iquilezles.org/articles/biplanar/

Edit: For those interested, here is information on Concurrent Binary Trees (please don't call the new system CBT, you will be made fun of) and their implementation:

https://onrendering.com/data/papers/cbt/ConcurrentBinaryTrees.pdf

Edited by Gameslinx
Link to comment
Share on other sites

Whilst one can most certainly appreciate any work being done, I can't believe the stuff I'm reading. PQS being limited garbage was known before KSP1 got to 1.0, and then y'all went and wasted time on it only to obviously have to throw it away? plus this gives much more credibility that this EA was just a tech demo propped up on the toothpicks that are both Unity's default systems and KSP1 leftovers. Big yikes. Further on, you spend multiple paragraphs talking about optimization only to end up removing graphics effects as the only real "optimization" coming up in a tangible timeframe.

Sad to know as well that the current visual style is actually accepted as good. It is vomitive, riddled with excessive bloom, dissonant brightness and overall sickening to the eyes.

All of this, slated for the "next few updates", when we're struggling to get the first one out, with a very thin fix list and zero new features. Meanwhile KSP1 gets volumetric clouds at a negligible performance impact.

Edited by PDCWolf
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...