Developer Insights #18 - Graphics of Early Access KSP2

[Guest]

Hand on heart, RocketRockington. Do you think those mountains look remotely as crisp, detailed, and "real" as the ones in the KSP2 screenies? Because "fuzzy blob" is pretty much how I'd describe them! 

(This is NOT intended as a slight to the people who made RSS/RO, that's some STELLAR work. But they had to work within the limitations of KSP1!)

Edited March 11, 2023 by Guest

[rebel-1]

This is all very interesting, but we have not received an answer to why the game, where the graphics are very primitive, has such system requests, and on systems where MSFS works with 60 frames per second with great graphics at high settings, KSP2 barely works at minimum settings with 11 frames.

[The Aziz]

5 minutes ago, rebel-1 said:

MSFS works with 60 frames per second with great graphics

I played MSFS. Still don't know where the "great" was. Looking at terrain, seeing the low res heightmaps with textures taken directly from bing maps that fail to accurately represent anything that's more wild than slight hills... MSFS did right the aircraft and atmosphere. Nothing else.

[Speeding Mullet]

10 minutes ago, rebel-1 said:

This is all very interesting, but we have not received an answer to why the game, where the graphics are very primitive, has such system requests, and on systems where MSFS works with 60 frames per second with great graphics at high settings, KSP2 barely works at minimum settings with 11 frames.

Here's a post on KSP2 performance that might fill in some gaps

Two identified areas are terrain optimisation, and fuel flow/resource optimisation.  I'm pretty sure there's a heap more on the list of things they need to/want to optimise.  Here's another post with information about optimisation:

I wouldn't call the graphics primitive in the slightest but I suppose that is a relative benchmark, much in the same way the dollar value of the game is depending on who you poll.

SM

[Shkeiru]

Maybe the question was already asked, but... Why did you not started by that ? 

[Wyleg]

1 hour ago, rebel-1 said:

This is all very interesting, but we have not received an answer to why the game, where the graphics are very primitive, has such system requests, and on systems where MSFS works with 60 frames per second with great graphics at high settings, KSP2 barely works at minimum settings with 11 frames.

We have. PQS+ is a resource hog. Loot at the timings in the first post.

[HopelessSoap]

4 hours ago, RocketRockington said:

Then put up some screenshots of KSP2.  And I'll see if I can match them with modded KSP1 screenshots that show that KSP1's engine could do just as well, no need to use this magic PQS+ system that does things that were 'impossoble' before.

Screenshots of Earth aren't meaningful in this discussion.

[gekavo]

How about working with NVIDIA and add DLSS and amd FSR  especially for nvidia 4000 3.0 version would give a lot of fps
and FSR 2.0 and in the future its 3.0 version, could improve performance on all other video cards. As soon as AMD releases fsr3.0, I'm sure that 1060 from this post could draw a more or less acceptable fps

[Guest]

2 hours ago, The Aziz said:

I played MSFS. Still don't know where the "great" was. Looking at terrain, seeing the low res heightmaps with textures taken directly from bing maps that fail to accurately represent anything that's more wild than slight hills... MSFS did right the aircraft and atmosphere. Nothing else.

I think the terrain in MSFS looks great!

 

[Vl3d]

13 minutes ago, Periple said:

I think the terrain in MSFS looks great!

 

Clearly there's no comparison. But it's interesting that this is a valid argument nowadays.. 6 months ago when I tried to compare KSP2 to any other flying or space game I got furiously attacked in the forum comments. Be careful what you write, what photos you post and what you link around here.

Edited March 11, 2023 by Vl3d

[Guest]

3 minutes ago, Vl3d said:

Clearly there's no comparison. But it's interesting that this is a valid argument nowadays.. 6 months ago when I tried to compare KSP2 to any other flying or space game I got furiously attacked in the forum comments. Be careful what you write, what photos you post and what you link around here.

I'll be really impressed if KSP2 reaches MSFS's level of graphical quality! I don't think it's impossible but on the other hand Asobo is about five times bigger than IG and they only have one planet to worry about so it's a bit of a stretch!

[A Generic Kerbal]

Rip, the game's dead 

[Kree]

5600x, 16gb ram and GTX1080, therefore a better position than the minimum required. The game with minimal configurations is unplayable. What are we talking about?

[The Aziz]

34 minutes ago, Periple said:

I think the terrain in MSFS looks great!

 

I could pull some questionable screenshots from MSFS for comparison but I don't think it's very on topic. In any case, most of the concerns are regarding upclose ground visuals, which even in flight sim aren't revolutionary.

20 minutes ago, Periple said:

Asobo is about five times bigger than IG and they only have one planet to worry about so it's a bit of a stretch

And they also have all the planetary data they needed from Microsoft, heightmaps, scans, aerial photos, most of it loads to your pc from their servers (you don't think the few hundred GB the game takes would be enough to hold the whole planet?)

[Arsonide]

I'm confused by the implication that High Definition Render Pipeline, a render pipeline that by Unity's own admission was not built with performance in mind, might help with performance. If anything it will enable a ton of fancy effects that will harm performance.

If performance is a concern then that is something I typically associate with the Universal Render Pipeline.

[PurpleLion]

Im glad that performance is being looked at but for me at lest i would happily trad a solid 60FPS for 95% reduction in kraken, bugs and a flaky 15FPS . fsp is no good to me if i have to keep reloading saves because of bugs it just kills the fun. 

The performance is not good currently and i hoped it would be better but and the end of the day its a Alpha and the performance good enough for testing.

 

 

 

[drhay53]

3 hours ago, The Aziz said:

I played MSFS. Still don't know where the "great" was. Looking at terrain, seeing the low res heightmaps with textures taken directly from bing maps that fail to accurately represent anything that's more wild than slight hills... MSFS did right the aircraft and atmosphere. Nothing else.

When MSFS first came out one of the big knocks on it was that it struggled to produce high frame rates on normal hardware even on low graphics settings. It's almost like it's been out for a couple of years now and had a lot of optimizations.

[Haustvindr]

1 hour ago, The Aziz said:

And they also have all the planetary data they needed from Microsoft, heightmaps, scans, aerial photos, most of it loads to your pc from their servers (you don't think the few hundred GB the game takes would be enough to hold the whole planet?)

I was around when they announced the tech details, but not directly giving attention. If I don't remember wrongly, I think they said that full quality, all bells and whistles, full planet... were talking about petabytes.

I may be wrong though, as I said I'm reaching my memory and was not really attentive enough.

[Cosmus]

Glad to see the team working so hard on the game. Keep the dev diaries rolling  

[mcwaffles2003]

2 hours ago, drhay53 said:

When MSFS first came out one of the big knocks on it was that it struggled to produce high frame rates on normal hardware even on low graphics settings. It's almost like it's been out for a couple of years now and had a lot of optimizations.

It's similar to KSP 2 in this regard because even on powerful hardware it struggled

[The Aziz]

If you look at a number of large PC game releases in the last couple of years, they all struggle on day one, like if optimization efforts weren't even there or were handwaved. Regardless of who did that, the dev or publisher, it feels like they're all facing crunch and are finishing the crucial parts of the work on last second, and it doesn't look like it's going to change any time soon.

[mcwaffles2003]

20 hours ago, Intercept Games said:

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 

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 

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. 

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.  

Thank you for the dev update. I find it fascinating to see how the game is made, how devs compare and contrast their developed techniques and how they affect performance.

Hope we see a lot more of these going forward and thanks again for the update

[KincaidFrankMF]

20 hours ago, darthgently said:

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.

This.

Although it doesn't necessarily need to be user configurable (other than a simple on/off option) - rather, it would be nice if the game dynamically responded to dropping framerates by automatically lowering the graphics settings and then upping them again when the system is under less strain.

It's far less jarring to see the odd pixel than having the whole game grind to a jerky halt. You see this kind of thing in e.g. racing games a lot - suddenly a chunk of car panelling is a big mess of pixels, just for a moment or two, but you don't reeeaaaally notice too much because the framerate didn't crash so you're still in full control of your vehicle.

One thing KSP2 does really smoothly is altering the graphics settings - you can do it without even pausing, and there's no clunky screen res shift or anything else to draw the eye. It just happens, instantly. So why not make use of that?

[darthgently]

46 minutes ago, KincaidFrankMF said:

This.

Although it doesn't necessarily need to be user configurable (other than a simple on/off option) - rather, it would be nice if the game dynamically responded to dropping framerates by automatically lowering the graphics settings and then upping them again when the system is under less strain.

It's far less jarring to see the odd pixel than having the whole game grind to a jerky halt. You see this kind of thing in e.g. racing games a lot - suddenly a chunk of car panelling is a big mess of pixels, just for a moment or two, but you don't reeeaaaally notice too much because the framerate didn't crash so you're still in full control of your vehicle.

One thing KSP2 does really smoothly is altering the graphics settings - you can do it without even pausing, and there's no clunky screen res shift or anything else to draw the eye. It just happens, instantly. So why not make use of that?

Yes, in interactive games, "flow" has been shown to be more important to immersion and enjoyment than resolution and detail.  Our sense of time is far more easily offended than our visual or auditory aesthetic.  Generally.  There are exceptions of course.  Making it dynamic, makes the most of both.

If not rule based, then maybe something as simple as a manual bump up/down and maintaining a specified frame rate.  I like the rule based approach though.  Several prefab selectable rules could be provided with a mechanism for mods or the geekier player to construct their own by way of some config file

[TheOrios]

thank you for not abandonning the game due to its poor launch