Developer Insights #12 – Planet Tech

[Intercept Games]

Hi, I’m Eric DeFelice, a graphics engineer on the KSP2 team. My job is to create technical solutions to the graphics features we have on KSP2. One of the most obvious of these systems is how we generate, position, and render the planets in the game.

We need a system to render the planets while in orbit and interstellar travel, as well as up close, on the planet surface. We want transition between these distances to appear as you would expect, as you get closer to the planet surface, you just see more detail. How do we solve all the problems associated with a graphics feature such as this? Can we just use traditional approaches for level of detail?

Lets dive a bit deeper into how we solve this problem in KSP2. I’ll try to give as much detail as I can without having this take an hour to read…

 

Basic mesh rendering & LOD systems
Lets start by looking at how most meshes are rendered in KSP2 (and most games for that matter). Generally, the mesh data is sent from system memory over to the GPU, where shaders read it, place it at the correct pixels on screen and output the correct color given some material properties. We could try and use this approach for our planets, but there are a couple big issues we would have when trying to achieve the level of detail we would like.

 

The biggest issues we would have revolve around the memory usage that it would take to store all that vertex data for planets that are as large and detailed as we have in the game. We could mitigate these problems with level of detail approaches, and perhaps trying to break up the planet into chunks, so we could only load in the chucks that are relevant. GPU tessellation is also a possibility, but that wouldn’t really give us much control over the terrain height. One other big issue has to deal with the size of our planets and precision issues when trying to position the planet in camera projection space. I’ll talk more about this shortly. 

 

Pre-Alpha, Not Final

Given these problems, we don’t use this basic approach when rendering planets up close. We do however use this basic approach when rendering planets from further away. This allows artists to have full control over the look of the planet from this distance, and is a good starting point to add more detail to as you approach the planet surface.

 

Planet Positioning
Another core gameplay feature we have to keep in mind when rendering the planets is that their position may be moved around relative to our floating origin (for more info, see the previous dev blog by Michael Dodd). For our planet rendering purposes, this means that our planet center will usually be further from the origin than its radius. If we defined the planet vertex data in model space, then during rendering, when we transformed its position to camera projection space, we could possibly be dealing with some large transformation values. If we then are viewing the terrain while it is close to the camera, creating very small distances in camera space, we may have some visual artifacts (as seen above).

How do we deal with this possible problem? Well, one simple solution is to generate the vertex data so it is relative to the floating origin already. That way we don’t have to deal with the model to world transformation, keeping the position values in a reasonable range.

So now that we have our key concerns listed, we can finally look at how we solved these problems in KSP2.

 

PQS System Overview for KSP2
In KSP2 we use a very similar PQS (procedural quad sphere system) that was used in KSP1 (here is much more detail in the basics of that system). We have made some updates to the system, namely that we now generate all of the planet mesh data in compute shaders. This planet vertex data never gets sent back to the CPU, and we just send a procedural draw call to the GPU to render the mesh with the compute buffer data.

 

We do determine quad sub-divisions in a similar way as KSP1, but we generate the output mesh positions relative to our floating origin, instead of relative to planet center. When calculating each vertex position, we also calculate the height, slope and cavity for the mesh so that we can perform procedural texturing in the planet shader. One caveat we needed to account for in our procedural parameter calculation is that we need to make sure we have stable values for any given position on a planet. This is needed because we don’t want the texturing to visually change at a given position, which could occur if the slope changes at that position because of mesh tessellation.

For tessellation, we have to balance the level of detail we want at various distances with the performance concerns of generating more vertex data. The goal is to bump the level of detail for the terrain at a distance that isn’t really noticeable, so we don’t have a ton of visual detail popping in. We are constantly improving in this area (for reference, here is some previous footage of our planet tessellation tech).

 

Pre-Alpha, Not Final

Pre-Alpha, Not Final

One other feature we have to help improve performance is basic frustum culling. Since we don’t have a bunch of mesh data on the CPU we can’t rely on traditional approaches for culling, so we have to do this on our own. Since we already have a bunch of quad data, we might as well just use their positions for this purpose. On the CPU we can determine which quads are within the camera frustum, and only generate visual mesh data for those. This prevents us from doing a bunch of work on the GPU that we know will be thrown away later, since that part of the mesh isn’t even visible.

 

Pre-Alpha, Not Final

PQS Collider System Overview
Terrain colliders need to be created by this system as well, since they rely on the mesh data for the planet. There are a few differences in the requirements for collision however. We no longer want to tessellate collision mesh data based on distance from the camera, but rather on distance from possible colliders that could hit that terrain. Because of this, we need to keep track of separate collision quad data.

We also can’t perform the same frustum culling that we do for the visual mesh, as a vessel could be out of view when it collides with the terrain. Can we still do some sort of culling though? You guessed it, we can. We just cull any terrain colliders that we deem too far away to possibly have a collision in that frame. This does the same job as frustum culling does for the visual mesh, prevents us from doing a bunch of work on the GPU that we know is useless.

 

Pre-Alpha, Not Final

 

Pre-Alpha, Not Final

Everything coming together
Hopefully I gave you some more insight into how we generate and render our planets in KSP2. The key goals of the system are to provide a high level of detail of the planet at all distances while maintaining a solid frame rate. There are many unique problems in KSP2 compared to most other games I’ve worked on, so we definitely had to get creative with our solutions.

One final tidbit I’ll leave you with, is our system for how we transition to our PQS generated mesh from the low LOD mesh. Borrowing a technique from basic LOD systems, we actually just perform a cross-fade dither between the two meshes.

And lastly, all the systems coming together!

 

Pre-Alpha, Not Final

 

Pre-Alpha, Not Final

View the full article

[AtomicTech]

8 hours ago, Intercept Games said:

For tessellation, we have to balance the level of detail we want at various distances with the performance concerns of generating more vertex data. The goal is to bump the level of detail for the terrain at a distance that isn’t really noticeable, so we don’t have a ton of visual detail popping in. We are constantly improving in this area (for reference, here is some previous footage of our planet tessellation tech).

 

The improvements are awesome! The rendering and the visuals are so smooth!

Many props to y'all!

8 hours ago, Intercept Games said:

Pre-Alpha, Not Final

 

Are we seeing the return of the Kerbal Whacker!?

Y'all made my day!

Thanks!

[Spaceman.Spiff]

Minmus looks AMAZING!

So happy to see it’s had a bit of a design adjustment. 

[BekfastDerp13]

YES YES YES I was waiting for this! I love it!

[TheOrbitalMechanic]

Looks cool! Glad to see all the improvements!

[prestja]

Help a layman astronomer out here - what type of star did we see in the last video?

Edited December 10, 2021 by prestja

[AtomicTech]

13 minutes ago, prestja said:

Help a layman astronomer out here - what type of star did we see at the end of the last video?

Debdeb, I think.

[Guest The Doodling Astronaut]

Looks great. Nice blend of visual and technical things

[MechBFP]

Just wanted to say thank you for the post. The detail was excellent and I hope the more knowledgeable members of the community are able to provide some helpful feedback to you guys as well.

1 hour ago, Intercept Games said:

We are constantly improving in this area

Looking like there is already significant improvements based on that short video compared to ones in the past. Good stuff.

I definitely understand the challenges associated with this one, so by no means would I expect perfection. I hope on PC however we have the ability to change the necessary graphical settings to make this even more seamless by sacrificing FPS if we choose to do so.

[shdwlrd]

Like seeing the technical side of game development. It looks like the collision detection subsystem will be well used throughout the game, not just for crafts or parts. 

[Hyperspace Industries]

46 minutes ago, prestja said:

Help a layman astronomer out here - what type of star did we see in the last video?

Red dwarf, probably.

Also, YAAAYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY *GASP* YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!i!!!!!!!!!!!!!!!

[Alexoff]

Wow, there is actual gameplay!

[Pthigrivi]

This is great and really clever. I know resources and prospecting will be a big deal in KSP2, any thoughts on displaying things like resource and biome maps and other gameplay information in flight? Kerbnet was a clever solution but I always wished I could just see all that painted on the terrain as I was landing rather than trying to extrapolate from a small window with a slow refresh rate. 

Edited December 10, 2021 by Pthigrivi

[Lewie]

Hot dog, that is looking good! Great work as usual, thanks for yet another insightful technical diary!!

[Davi SDF]

Nice! I don't really have anything more to say right now, so i wish you all the best!

[Scarecrow71]

First off, I'd like to send massive kudos out.  This is quality work being done, and the devs I'm sure don't get enough love for it.  Well done.

Secondly, my impressions (for what they are worth) of the gameplay video.

1. Not a real fan of putting the Kerbals at the top of the screen.  Generally speaking, our eyes tend to move either up or down naturally, which means we will always be looking either top-center or bottom-center for information.  The Kerbals, while awesome, are not what I'm looking for when looking at the screen (although, I do need to know where they are for EVA).  I'm guessing there is some other gameplay-related reason why they are up there?
2. I dig the redesign of the navball and SAS module on the left of the screen.  Buttons are bigger, and it seems easier to read.  And it looks like there is added stuff there; perhaps more controls for flight?  Don't know for sure, but it looks nifty to me.  It looks like they incorporated relative altitude in the navball, which is nice to have right there next to everything else you need to pay attention to.
3. I love that they moved the time warp controls and made them stay on the screen.  One of my biggest peeves about KSP, even though I tend to use keyboard shortcuts, is that time warp is hidden under the MET button top left.  This way it's right there, in front of you.  And, as I pointed out in #1 above, it's critical information that your eyes will naturally move to as it is bottom-center of the screen.
4. It looks like staging, which has moved from the left side to the right, has been re-ordered.  Looks like stages are now numbered in the order you activate them, not top-down.  So the engine is stage 0, the decoupler stage 1, the parachute stage 2.  Not a big deal, and makes sense.  Just have to keep that in mind when flipping from KSP to KSP2 lest you stage wrong.
5. Not sure why, but during descent the navball doesn't show that the ship is pointed to retrograde.  In fact, the navball doesn't look like it's moving at all.  Could just be because the purpose was to show off the rendering of the planet, but still noteworthy.  At least, it's noteworthy in my opinion.
6. Why is Elias laughing maniacally as they are going into the surface at terminal velocity?  He has to know he's about to die.
7. Love the scattered, broken parts upon impact.  Currently all we get is an explosion, which is fine.  But detail like shrapnel flying off everywhere, even if it doesn't do anything else, is still a cool effect.

All told, love the update.  I love that they've done some upgrades to planet texturing, and it's also cool to see that they are taking some player suggestions and putting them in the game (redesigns and look/feel).  Keep up the good work; I am looking forward to the day when I can send you some cash for this game!

[gussi111]

What I liked the most is:

1) the color of that star looks so amazing on the horizon, it seems we will have eye candy sunsets that will look incredible!

2) I love how the game doesn't freeze when the craft is about to crash and some parts fall down lower without just a single explosion, awesome!!

[HebaruSan]

10 hours ago, Intercept Games said:

Hi, I’m Eric DeFelice, a graphics engineer on the KSP2 team.

Hi, and great post! One technical thing I'm curious about...

10 hours ago, Intercept Games said:

One other feature we have to help improve performance is basic frustum culling. Since we don’t have a bunch of mesh data on the CPU we can’t rely on traditional approaches for culling, so we have to do this on our own.

This made me wonder about how backface culling fits in. It would be a 50% savings if the half of a planet on the opposite side of the camera didn't need to be rendered at all. But in principle, it's possible that a particular area of a planet might be overall facing "away" from the camera as defined by its bounding vertices, but then the terrain between those vertices might poke out and still be visible. I guess this would correspond to a mountain peak rendered from the side, roughly.

Most approaches that come to mind are heuristics, such as requiring those vertices' plane to be facing away from the camera by more than a certain angle (say 10 degrees) rather than just a strict yes or no, to give mountains some space to fill in. I was wondering whether your team has created a more creative, generalized solution to this?

[Admiral Fluffy]

3 hours ago, Intercept Games said:

 

Pre-Alpha, Not Final

Nice final draft you've got there!

3 hours ago, Intercept Games said:

 

 

Thats a beefy computer.

[AtomicTech]

20 minutes ago, Scarecrow71 said:

Why is Elias laughing maniacally as they are going into the surface at terminal velocity?  He has to know he's about to die.

[gussi111]

3 hours ago, Intercept Games said:

 

 

Around 0:26 you can actually see inside the cockpit through the window? Wow!

[StarSlay3r]

3 hours ago, Scarecrow71 said:

First off, I'd like to send massive kudos out.  This is quality work being done, and the devs I'm sure don't get enough love for it.  Well done.

Secondly, my impressions (for what they are worth) of the gameplay video.

...

Everything you see is work in progress. Kerbal reactions/animations, craft collision effects, etc. seen in the video are not final. The team is still working on various aspects of the game, and things are continuously changing.  

Our graphics and UI teams are working on separate parts of the game, so older UI still pops up in some test footage. The flight HUD is being completely overhauled, and what you see here is just leftover old UI.

[Alexoff]

It is strange that on the last video the planet is drawn with lines like dunes of sand, and at 32 sec a rocky planet with craters seems to shine, which is somehow unrealistic

[t_v]

Could you elaborate? Maybe there’s something I’m missing. For the sand, I can attest to the fact that parallel shadows are common shader glitches, so I can’t say anything to that, but for the reflectiveness, most surfaces in a vacuum will be reflective even if those surfaces are dusty with debris from impacts. Also, even in atmospheres, rocky surfaces are reflective. 

[Anth]

Loving all the information on what is going into the games inner workings and the improvements over KSP1.

And I loved the video with the vomiting of the blue pills