Let's talk performance ... or lack thereof

[ShadowZone]

I got a big gripe with KSP and that is performance.

Actually it is my biggest issue with the game, period.

As some of you may have noticed, my rockets and ships tend to lean on the larger side with hundreds of parts being used. I created an entire setup of how I would use stations as waypoints for an interplanetary mission but I never manage to realize it because as soon as my (giant) station and my (humongous) ship come into reach of each other, the game freezes to a halt. 5-6 fps or even less are what I experience daily.

I have tried using Active Texture Management. I removed the clouds mod which I love and which added so much atmosphere (pun intended) to the game. Now at least the game doesn't crash every 5 minutes but it is still almost unbearable.

I don't know about all of you, but all the things the devs did in the updates of the past months did not alleviate these problems. We got more parts (which I like), we got contracts (which I don't care much about, I spend 90% of my time in Sandbox) and we are getting better aerodynamics (which are discussed elsewhere). But what about performance? I feel like there could be a lot more Squad could do in that department.

Am I missing something? Am I the only one with this complaint? Because I don't see it voiced a lot...

[worir4]

I think that now the game is in beta we will see performance improvements. Just hold on a few months more!

[ShadowZone]

One can only hope...

but has there been any official word on that yet? I always read about new features and changes to features but nothing regarding the "meat" of the software.

[rynak]

The problem is multifold:

#1: It's developed with unity. Unity is slow - KSP is far from the only victim. However, at this point squad will not go and rewrite the game from scratch for a different platform.

#2: Everything is programmed in .NET, because that's how unity works: What with another game you would go and implement the most time-critical code in C or CPP and optimize it, in this game everything and the kitchen sink is coded in .NET, including yes - physics. Again, that's a unity limitation - so not going to change.

#3: Inefficient usage of textures. ATM only fixes this partially for two reasons: A) It doesn't address duplicate textures, It resizes blindly, without taking into account (visually) what is needed. A completely white single-color 512x512 still is a waste, even if you resized it down from 2048x2048 (YES, i've seen this... plenty of times). I'm not sure if ATM compresses anything else than textures of parts and interiors... there are a lot of wasteful textures in the assets.

#4: Most debug logging code is compiled into the game, so the CPU's branchcache is trashed with endless "IF DEBUG == 1" checks. This probably is a minor issue but still contributes to an already scarce performance budget.

EDIT: #5: The way planets are implemented. Again, almost certainly a unity limitation.

Edited January 18, 2015 by rynak

[Captain Sierra]

A lot of us have it but we don't complain because there are limits to what Squad can do. Part of the problem lies in a) KSP being a very physics-heavy game and Unity only being able to handle game physics on one processor thread.

The other issue is that several-hundred part ships are going to do that, period. There is a limit to what is possible without lag and Squad will never be able to remove that entirely.

Ocean lag, on the other hand, is a horrendous issue that needs to be addressed. There is no real reason that needs to exist and if it takes Squad an entire update to do nothing but rework how oceans work so they don't lag harder than a Whackjob rocket, so be it. Ocean and planetary lag need to be addressed.

Light lag is a deficiency of Unity (and many other game engines) not handling lots of light sources (especially overlapping lights & shadows) very well.

Back to part lag, one solution is to slow down the game sim speed. Space Engineers and EVE online both combat physics lag in this way. Due to the way time works in KSP, I do not believe it is possible for this to work as a background system like it does in those games. TimeControl is a mod which implements this already in a rather achievable way. An implementation like this (where players can enable/disable time dilation, set a fixed multiplier, or toggle automatic dilation) would be a solid option, a sort of reverse phys-warp. This has been addressed by multiple mods before and presently, so I don't believe its too hard for Squad to do.

Another option (which sadly has been veto'd out of stock multiple times) is to part-weld. Part welding works reasonably well to cut down part count and doing it correctly will knock it by 40-50%. This is addressed by a mod but frustratingly has been cast off as a straight up 'no' by the dev team, at least for the stock game.

We feel your pain, and relief should be coming soon. How soon we cannot say, but Squad does know this is an issue so we can safely assume they'll be looking into solutions before we get out of beta.

[juanml82]

I was thinking on making a similar thread.

The question is: when is Squad going to optimize KSP?

Right now, KSP loads every texture in the game into RAM and, unless something changed with the last update, they were using png images which I understand is a very inefficient way to handle textures in a videogame. There is a thread to force Opengl to reduce ram consumption, as well as a mod to load DDS for textures to speed up start times. When is Squad going to officially work this issue? KSP isn't cutting edge graphics - it's actually budget/outdated/cartoonish graphics and is facing performance issues games with incredibly better graphics don't have. Really, check any AAA game from the last 3-4 years. They don't need to be 64 bits because they need more than 4GB of RAM because of textures. They run perfectly fine, even with graphic mods, as 32 bits processes.

Physics: Squad chose an engine which lacks multicore support. That may be a mistake on their part if the pros didn't outweight the significant drawbacks. But where is the need to calculate physics in every part of a ship which isn't affected by external forces. Take a massive space station, outside the atmosphere and not being hit by a nearby ship's exhaust. Or a planetary base firmly on the ground. Why is the game coded to calculate physics for every single non massless part, if the result is going to be the exact same as in the previous frame - no changes, because no new force is affecting the vessel.

The game has been around for years now. Scope completion has been reached. Is Squad ever going to focus in optimizing it?

[rynak]

But where is the need to calculate physics in every part of a ship which isn't affected by external forces.

This, and it also is relevant to the planned update of aerodynamics. Why is it neccessary to calculate everything from scratch, each frame? Is that accuracy really neccessary? I'm not suggesting to never check every single tiny part, but wouldn't every 2nd or 3rd frame be sufficient?

[ShadowZone]

The problem is multifold:

#1: It's developed with unity. Unity is slow - KSP is far from the only victim. However, at this point squad will not go and rewrite the game from scratch for a different platform.

#2: Everything is programmed in .NET, because that's how unity works: What with another game you would go and implement the most time-critical code in C or CPP and optimize it, in this game everything and the kitchen sink is coded in .NET, including yes - physics. Again, that's a unity limitation - so not going to change.

I heard about Unity 5 enabling multicore physics rendering. Should we expect a significant performance boost from that?

[rynak]

I heard about Unity 5 enabling multicore physics rendering. Should we expect a significant performance boost from that?

It won't address the problems i mentioned, but distribute some of them over multiple cores.... it depends on *what* exactly unity5 allows to run on seperate cores. "Multicore support" doesn't mean that everything magically and arbitrarily is distributed over cores... but rather, selected parts of the engine. If for example physics could have their own core, that would help KSP. If the renderer could have its own core, that would help, and so on. Again, the overall inefficience wouldn't change - just the workload be distributed.

The issues about textures and planet rendering however, almost certainly won't benefit, cause it's the GPU that mostly takes a hit from this (and it also wouldn't help physics, because if you put physics on a different core, you still have physics on just one core.... just perhaps a less busy one).

So yes, depending on how much and what unity5 they multithread, there would be a boost - some bottlenecks would remain though.

[juanml82]

This, and it also is relevant to the planned update of aerodynamics. Why is it neccessary to calculate everything from scratch, each frame? Is that accuracy really neccessary? I'm not suggesting to never check every single tiny part, but wouldn't every 2nd or 3rd frame be sufficient?

Honestly, with engines off, outside the atmosphere and not maneuvering, don't check. At all. Why even bother? The same conditions are always going to end up in the same result

[Tuareg]

It won't address the problems i mentioned, but distribute some of them over multiple cores.... it depends on *what* exactly unity5 allows to run on seperate cores. "Multicore support" doesn't mean that everything magically and arbitrarily is distributed over cores... but rather, selected parts of the engine. If for example physics could have their own core, that would help KSP. If the renderer could have its own core, that would help, and so on. Again, the overall inefficience wouldn't change - just the workload be distributed.

The issues about textures and planet rendering however, almost certainly won't benefit, cause it's the GPU that mostly takes a hit from this (and it also wouldn't help physics, because if you put physics on a different core, you still have physics on just one core.... just perhaps a less busy one).

So yes, depending on how much and what unity5 they multithread, there would be a boost - some bottlenecks would remain though.

im already working with unity 5 and i can say itsatrap... itsamagic... physics can be 7 times faster so nvidia has done some real good job with Physix (and its just the cpu level physics, those have cuda compatible nvidia cards can gain even more) so if squad doesnt mess up something you will be able to enjoy HUGEHUGEHUGE rockets after they upgrade to u5. also the 64bit seems to be fully stable so yeah ram limit is gone. on the other hand it will not solve the multithreading of ksp, its still a work squad has to do, i dont know how far they are in it and the audio/lightnings and particles will still hit the gpu-s and can make everything a lagfest even on the strongest pc-s. with u5, there will be no "but its unity" excuse for squad...

[KerBlam]

Unity 5; the hero Kerbol deserves.

[ShadowZone]

im already working with unity 5 and i can say itsatrap... itsamagic... physics can be 7 times faster so nvidia has done some real good job with Physix (and its just the cpu level physics, those have cuda compatible nvidia cards can gain even more) so if squad doesnt mess up something you will be able to enjoy HUGEHUGEHUGE rockets after they upgrade to u5. also the 64bit seems to be fully stable so yeah ram limit is gone. on the other hand it will not solve the multithreading of ksp, its still a work squad has to do, i dont know how far they are in it and the audio/lightnings and particles will still hit the gpu-s and can make everything a lagfest even on the strongest pc-s. with u5, there will be no "but its unity" excuse for squad...

I read a lot about "nvidia" regarding the unity5 improvements... what about Radeon users? Will they benefit as well?

[Tuareg]

I read a lot about "nvidia" regarding the unity5 improvements... what about Radeon users? Will they benefit as well?

yes, as i wrote the improvement is cpu based so the graphics card doesnt matter. an nvidia card just gives even more extra