Kerbal Space Program | Developers Insights

 KERBAL SPACE PROGRAM

DEVELOPER INSIGHTS

We truly need a method to make the planets whilst in orbit and travel that is interstellar as well as in close proximity, on the planet's surface. We want the transition between these distances to appear as you have closer to the planet area, you merely see increased detail as you'll expect. How do we solve all of the nagging problems of a graphics function such as this? Can we simply utilize conventional approaches for the amount of information?

Let's plunge a bit deeper into exactly how we resolve this nagging problem in KSP2. I’ll make an effort to provide as much detail that is much I can without having this just take an hour to read…

 

Fundamental mesh rendering & LOD systems

Let's start by taking a look at just how many meshes are rendered in KSP2 (& most games for instance). Generally, the mesh data is sent from system memory up to the GPU, where shaders read it, put it at appropriate pixels on-screen, and produce the color that is right some product properties. We're able to attempt to make use of this approach for the planets, but there are always a couple of problems that are big might have when trying to attain the level of detail you want.

The largest problems we would have to revolve across the memory usage even as we have within the game that it would just take to keep all that vertex information for planets which are as large and step-by-step. We're able to mitigate these issues with the level of detail approaches, as well as perhaps attempting to break the planet up into chunks, so we could just load within the chucks which are relevant. GPU tessellation is also a chance, but that couldn’t really give us control that is much the landscape's height. One other issue that is big to deal with how big is our planets are and accuracy problems when attempting to position our planet in the digital camera projection area. I’ll talk more about this shortly.

Provided these problems, we don’t utilize this approach that is fundamental rendering planets up close. We do nevertheless utilize this approach that is basic rendering planets from further away. This allows artists to have the control that is full the look of the planet using this distance and is a great starting point to incorporate increased detail to while you approach our planet area.

We do figure out quad sub-divisions in a fashion that is similar to KSP1, but we create the output mesh positions relative to our floating origin, in the place of relative to planet center. When calculating each position that is vertex we also determine the height, slope, and cavity for the mesh to ensure we could perform procedural texturing in the planet shader. One caveat we needed seriously to account for in our procedural parameter calculation is we've stable values for almost any offered position for a planet that people need to ensure. This really is required because we don’t wish the texturing to alter at a visually provided place, which could take place in the event that slope changes at that position as a result of mesh tessellation.

One other function we need to assist in improving performance is frustum culling which is basic. We can’t rely on old-fashioned approaches for culling, therefore we have to try this on our own since we don’t have a lot of mesh data in the CPU. We may also just use their roles for this specific purpose since we already have a lot of quad information. In the CPU we can determine which quads are inside the camera frustum, and only generate a mesh that is visual for the people. This prevents us from doing a lot of work with the GPU that individuals understand will away be tossed later since an element of the mesh is not even visible.

PQS Collider System Overview

Terrain colliders should be developed by this operating system as well, simply because they depend on the mesh information for the earth. There are always differences which can be few the requirements for collision nevertheless. We do not desire to tessellate collision mesh data predicated on distance from the camera, but rather on distance from possible colliders which could strike that terrain. This is why we have to keep track of split collision quad data.

We also can’t perform equivalent frustum culling it collides utilizing the terrain that we do for the artistic mesh, as being a vessel might be away from view whenever. Can we nevertheless do some sort of culling though? You guessed it, we are able to. We simply cull any surface colliders that people consider too much away to perhaps have a collision for the reason that frame. This does the task that is exactly the same as frustum culling does for the visual mesh, preventing us from carrying out a couple of focuses on the GPU that people understand is worthless.

Everything coming together

Hopefully, you had been provided by me personally some more insight into exactly how we generate and render our planets in KSP2. One of the key goals of this system is to offer a high amount of detail of this planet at all distances while maintaining a frame rate that is solid. There are many problems that are unique KSP2 contrasted to many other games I’ve worked on, so we surely had to get imaginative with our solutions.