Kerbal Mythbusting: Debunking Rumors and False Notions about KSP

This article is in no way affiliated with the TV show Mythbusters.


Over the past few months, I've noticed there is a large amount of misinformation and generally incorrect statements being passed off as fact around the KSP community, so I thought I'd take this opportunity to set some of those things straight, and have these 'myths' about KSP properly explained.

I don't mean to point any fingers about how these things got started... These tales have a way of growing in the telling, so it's likely no one's fault actually... Just things that never got properly explained, and grew more and more inaccurate over time.

So, let's get started here. Time to debunk some myths about KSP:


Myth #1: Unity and Multiple Cores.

The Myth:
People have been tossing around the 'fact' that Unity (and KSP) is stuck on a single CPU core. I've heard several variations of this, with varying degrees of inaccuracy. I've also heard claims that the performance improvements from the port to Unity 4 are because it's added multi-threading, or something like that.

The Truth:
Unity has always used multiple threads (and therefore multiple cores) as far as we've been developing KSP.
However, what Unity doesn't allow us to do, is write game code outside the main game thread. That is, we can spawn threads by code if we want, but Unity won't let you call any of its own methods or use its classes on those other threads.

This means game scripts are all running on one thread (and a single core, yes), but it does not mean Unity is using a single core. Unity, as of version 3.5, has all of the CPU-side of the rendering work (the processes that happen before the frame is sent to be drawn on the GPU) happening on another thread. Other systems, such as particle FX, mesh skinning, sounds and some other stuff, are also handled on other threads.

As for Unity 4, it didn't implement any new features regarding multi-threading. It did bring a number of performance optimizations to the engine itself, which in turn make KSP run faster and smoother. More specifically, on Windows, it implemented SSE2 instructions for some Physics operations (OSX already had that).

Conclusion: Busted.

Sources: http://unity3d.com/unity/whats-new/unity-4.0 (unity 4 changelog)


Myth #2: N-Body Physics

The Myth:
Legend goes that the reason KSP has no multiple-body gravity simulation is because of some technical limitation on our or Unity's end. That limitation prevents us from being able to simulate perturbations from other gravity sources and Lagrangian points.


The Truth:
This is false. KSP only supporting a single gravity source at any time is a decision we made deliberately here. Yep, it's not a bug, it's not an incomplete feature, it's meant to be like this by design.

This "limitation" is what makes many of the things you see in the game possible, or at least usable... Let me try and explain it:

The usual way games simulate physics is by a process called Integration. This process works basically like this: To know the position and velocity of an object, you take the position and velocity that object had on the previous frame, add in all the forces currently acting on it (using the object's mass to calculate the acceleration from those forces), add that to the current velocity, and move the object by however much it would move going at that speed in the time that elapses between each frame.

That means the state of an object at any point in time is only known if you know its state at the previous point in time, and the same goes for that point in time, and for the one before it, and so on....

So, to figure out the state of the solar system at any point in time, you need to start at a known starting point, and run the simulation forward until you get to that point.

Sounds ok, until you have to warp time.

If you start making time run faster, you can do one of two things: One, start simulating faster, so we keep up with the clock, or assume each frame spans a longer amount of time, and just move objects forward by the new amount of time.

With the first method, it obviously becomes apparent that the computer will have to start working overtime if you want to catch up. If you warp time to 5x, that's 5 times more calculations it would have to do in the same amount of time... not good. Now, imagine warping time at a hundred thousand times the normal rate. Quite impractical.

The second method won't melt your CPU down as much, but it's also problematic. Imagine you're orbiting Kerbin. At 1x, integration is perfectly ok. But what happens when time is running so fast, you cover half your orbit in a split-second? What happens then is that you never really calculated all that way you went around the planet, and now all of a sudden you're meant to be moving completely the other way around... That's not doable if all you know is that one frame earlier, you were at a particular position with a particular velocity, and a gravity was pulling towards some general direction.... You just don't have enough precision to simulate the physics at that rate, and then weird things start happening, like orbits shooting out of the solar system, of things mysteriously smashing into other things... It's not pretty.

So, what we do here is something completely different. If your physics system consists of a single gravity source and objects orbiting it, then there are equations you can use that will tell you your position, at any given time. This is called the 2-body problem, and it basically means we can just ask the game "where will I be on Year 1, Day 42, at 2:42pm", and it will tell us the answer with absolute precision.

This is what's known as a 'deterministic system'. At any point, the state of the system is known, or rather, can be calculated.

We decided to use this method in KSP, because it adds more things than the restrictions it imposes take away. Sure, we lose the ability to simulate Lagrange points, or orbital decay due to perturbations from a moon or something, but we gain a lot. We gain being able to save the game and advance time without having to run the simulation. We gain being able to predict (and get it right) where your current trajectory will take you, and we also get to do fun stuff like turn off normal physics entirely, and let ships coast "on-rails", indefinitely, and with total stability.

Long story short, this system is what makes things like Patched Conics, Time Warp, Flight Planning and multiple vessels possible.

And to be perfectly honest, orbital perturbations really aren't a lot of fun... most of the time they just push you away from the predicted path, and just make things generally more frustrating.

Conclusion: Busted.