KSP should still be able to run at 60fps even with mods. Discuss.

[TimKerbin]

This is just a rant about KSP's memory and GPU/CPU usage. How good/bad do you think it is?Can it be improved?

KSP isn't, by a long way, the most graphically taxing game out there. Compared to the kinds of graphics demands we see in other modern games - even on their lowest settings - the graphics demands in KSP are minimal by comparison, especially in vanilla. Which makes it so frustrating how this game can grind to a virtual halt just because you wanted to install one or two mods, or because you happened to have been playing for 5 hours straight. Even though my PC is at least 7 years old (2GB video RAM, 16GB of installed RAM,  an i7 multicore processor) it still more than meets the game's current MINIMUM specifications as set by Squad. The fact an old bucket like mine can still run this game fairly well, even with many mods installed, says it all. But do I sound like an entitled little gamer when I say that if I have 7GB of RAM available (as shown in Task Manager) I expect the damn thing to be able to access it, and it can't. Even in 64-bit! Or perhaps  this is still more of a Windows problem than a Unity problem? Or both?

I just get the feeling that KSP could and should be able to run at least 60fps even with many mods installed, and it's frustrating that it doesn't. Depending on the scene I can get maybe 24-30fps (in v 1.6.0), but that depends heavily on how busy the scene is. While docking with a moderately sized station it can drop to 9-12fps (I thought 1.6.0 was suppose to improve multicore rendering for multiple ships, but I really can't see any difference);  in maximum time warp I've seen it drop to 6fps and then shoot back up to 20 then back to 8. Indeed the framerate can be VERY inconsistent with frequent lag, and again I can't tell if it's my PC (toggling V-sync makes little difference, nor does setting a frame limit) , the mods, or the game engine. And please don't tell me to stick to vanilla; mods have defined this game just as they have defined SkyRim. Even Squad members themselves (Nova Silisco for example) contributed mods to this game. KSP just isn't appealing to me any more in vanilla, because I KNOW KSP can do so much better. The forums are always full of players suggesting or requesting new mods, especially visual enhancements, which says to me the community wants this game to be as good as it can be, and we really need to be asking if it is. Even after Unity5 and 64-bit mode were introduced.

I'm not a programmer but I can't help feeling that despite the move to Unity5 and its undoubted improvements, KSP still isn't running at its full potential; and it feels as if it never will as long as it's still using Unity. Programmers, mod-makers feel free to disagree.

My suggestion to Squad-Private Division: stop producing DLC and focus instead on continuing to improve how this game already uses available resources. No point in creating more 'stuff' for the game if in turn the game becomes so bloated and slow no-one can play it. No-one should need a StarCitizen-type setup to play this game satisfactorily, it ain't Star Citizen!

[Galileo]

It’s the physics of the game, not the graphics that slow it down. 

Even the top processors will have trouble keeping up with the physics, mind you, on every single part in game. People that like to build massive vessels with hundreds of parts tend to have a problem with that and have made many threads like this one.

Games like star citizen do not simulate physics like KSP does. Can’t compare apples and oranges.

[Sunius]

2 hours ago, TimKerbin said:

But do I sound like an entitled little gamer when I say that if I have 7GB of RAM available (as shown in Task Manager) I expect the damn thing to be able to access it, and it can't.

That's not how RAM works. Just because you can access it doesn't mean you will. Are you also going to complain about it not using up all free space on your hard drive?

In any case, I found that frame rate some times drops badly. I actually looked at it and found that steam overlay was taking significant amount of time even when it wasn't rendering anything. Disabling it gave some nice improvements.

Edited July 20, 2019 by Sunius

[Guest]

It’s not the graphics as has been said already but seems to be the physics. I used to use a $3k gaming PC to play this (downgraded to a laptop) but KSP would still come grinding to a stuttering mess if I loaded craft with high enough part counts. It’s a shame. But I thinks short of getting a KSP2 we are stuck with the limitations.

Edited July 20, 2019 by Guest

[Rocket In My Pocket]

GPU and RAM mean little to KSP. (Aside from over all RAM limiting how many mods with assets you can install.)

CPU, specifically single core performance is the limiting factor due to all the physics calculations. Considering that this is the opposite of how 99% of games work, it's not likely to be improved, quite the contrary; newer cpu's are going the way of more and more cores, further diluting single core performance. (Currently KSP can use multiple cores if there are multiple vessels on screen, one per. You can't split a single physics object up between cores though.) Barring some huge advance in multi-threading physics calculations on a single object (no small task mind you), it just is what it is.

Why is "multi core'ing" a single physics object difficult? Well, to use a very simplified example; imagine you have one dish to wash in the sink, with one tap, one dish rag, and I give you one helper. Do you take turns scrubbing? Wasting time passing the dish back and forth? Do we break the dish in half, each wash his piece, then re-assemble them at the end? Do you hold the dish and operate the tap while he scrubs? Do any of these sound faster or neater than just washing the dish by yourself? Now imagine I give you 7 helpers! 8 people in total...how will you utilize them to wash that single dish without having them get in each others way or just complicate the process? Kind of sounds like the fastest, easiest way is still to have 1 person just wash the dish while the other 7 watch right? Now imagine that for every helper I give you, I make you all younger, thus making all of you less proficient at dish washing; who can wash a single dish faster? A lone 40 year old, or 10 4 year old's? (One powerful processor vs. several weaker ones.)

Edited July 20, 2019 by Rocket In My Pocket

[cantab]

Well first up, no game can prevent a buggy or flawed mod from slowing it down, not without heavy restrictions on modding that would eliminate most popular KSP mods.

I think KSP's performance problems come from a couple of sources. Firstly, the way KSP simulates vessel physics as a set of connected rigid bodies. It's a "natural" way to do it when your vessel building works that way, and a lot of somewhat-realistic structural behaviour emerges from it. But it's inherently difficult if not impossible to multithread and CPU demand scales worse than linear with part count. Optimising the physics engine will only ever increase the part count needed to lag the game, to actually get rid of physics lag would require a completely different way of simulating vessel physics. Treating the whole thing as rigid (besides robotic joints) would do the job but then you wouldn't get the spectacular vessel explosions that the game has become famous for.

A second source is the Unity engine's problems with garbage collection. In simple terms, the entire game has to periodically freeze for the engine to do some behind-the-scenes stuff. This is why KSP often experiences regular stuttering. The problem affects any Unity game. It can be mitigated with clever programming but that requires coders to do that. Important to the current discussion, that includes developers of game mods. The garbage collection problems will only really go away when Unity fix it. (And then KSP has to be updated to use the new Unity.)

In short, KSP's performance problems come down to decisions made by Squad when KSP was first made, and they were at that time entirely reasonable decisions. Many years on, it's not easy to change it.

[JERONIMO]

Wow, really? My game flows at stable 60 FPS with some times getting down 50 FPS. I had never encountered the problem with a ship over 200 Parts... Maybe I need to install more mods? Anyway, as everyone above said, it's the physics that kill your PC. As @cantab mentioned, unity is a garbage collector... I wish there was an engine like Unity but without the garbage part...

[Superfluous J]

I should be among the idle rich. Life is full of shoulds that just aren't going to happen.

[Lisias]

22 hours ago, TimKerbin said:

I'm not a programmer but I can't help feeling that despite the move to Unity5 and its undoubted improvements, KSP still isn't running at its full potential; and it feels as if it never will as long as it's still using Unity. Programmers, mod-makers feel free to disagree.

Yep. You are not a programmer.

CPU is a finite resource - you use CPU cycles on something, you can't use that cycles on anything else. And when some CPU vendor suddenly has to disable a crucial performance feature on their CPUs due bad decisions on the past (I'm talking to you, Intel!), then suddenly a lot of CPU cycles are not available anymore and things that used to work fine now don't.  

The problem with home made Add'Ons is that very few people are skilled programmers able to take the best design and implementation decisions - and the ones that are, most have very little sparing time in order to check their decisions against a nasty and harsh entity: Reality.  

You can't have the cake and eat it too. And one size doesn't fits all.

These simple phrases resumes the worst problems software developers have to face in order to get the job done - on an environment that's changing everyday, and not necessarily for the better.

[linuxgurugamer]

1 hour ago, JERONIMO said:

Wow, really? My game flows at stable 60 FPS with some times getting down 50 FPS. I had never encountered the problem with a ship over 200 Parts... Maybe I need to install more mods? Anyway, as everyone above said, it's the physics that kill your PC. As @cantab mentioned, unity is a garbage collector... I wish there was an engine like Unity but without the garbage part...

Then you would need infinite memory.  It’s the nature of the language, in fact, most modern languages have it in one for or another

[klgraham1013]

22 hours ago, Galileo said:

It’s the physics of the game, not the graphics that slow it down. 

Even the top processors will have trouble keeping up with the physics, mind you, on every single part in game. People that like to build massive vessels with hundreds of parts tend to have a problem with that and have made many threads like this one.

Games like star citizen do not simulate physics like KSP does. Can’t compare apples and oranges.

I agree with everything you said except about the apples and oranges.  I compare them all that time, and apples are clearly better.

[Lisias]

26 minutes ago, linuxgurugamer said:

Then you would need infinite memory.  It’s the nature of the language, in fact, most modern languages have it in one for or another

To tell you the true… There's a memory management approach that I think it could be used to get an acceptable common ground. Mark and Sweep (Mark and Release for old farts that used to program in Pascal or Modula).

There're mainly two kind of memory allocations on a 3D engine as Unity: persistent ones (used for meshes, textures, code and static data) and temporary ones (used for meshes transformations, dynamic texturing, and all kind of temporary memory as the one used on "foreach" loops).

That temporary ones are the problem. At 60 FPS, each frame you draw will consume a fraction of the memory as temporary data - and almost none of "long term persistent" ones. At 120 FPS, you double the temporary memory allocation for doing the same job (one second of the game). And this is why I recommend people to use the lowest FPS they can be comfortable using - to lower the demand for that temporary data and relief a bit the Garbage Collector.

But I digressed.

If all that data being allocated for temporary tasks each frame, instead of being drawn from the HEAP managed by a GC, could be drawn from a Mark/Sweep one, you could simply get GC out of the equation on the FPS thingy: on the beginning of the frame, the Engine would Mark the current position of the Pool, and let things eat the memory as they please. On the end of the frame, the Engine would Sweep all that memory back to the pool.

Things in need to allocate "persistent" memory would need to ask it explicitly from the GC managed pool.

To have both managers alive at the same time, one of them would need to consume memory bottom up, while the other top down - the the GC, at the rare occasions it would need to be called, would need to carry some extra tasks to compact the memory under its control to keep it out of the way of the Mark/Sweep engine.

Of course things will not work so easy on Real Life, but yet, it's an plausible way to minimize the impact of a GC dependent language on a Real Time, Mission-Critical task as rendering a 3D World on a heavily memory hungry game.

Edited July 20, 2019 by Lisias
The auto-complete has bitten me. Why it doesn't works to prevent the tyops? :(

[magnemoe]

20 hours ago, Sunius said:

That's not how RAM works. Just because you can access it doesn't mean you will. Are you also going to complain about it not using up all free space on your hard drive?

In any case, I found that frame rate some times drops badly. I actually looked at it and found that steam overlay was taking significant amount of time even when it wasn't rendering anything. Disabling it gave some nice improvements.

More so ram double as disc cache, this is shown as free as its just an temporarily storage but very visible in game with lots of loading like Skyrim or FO4. If you return to an area loading is much faster with plenty of ram its still in memory. 

And yes physic is the real killer in KSP, more so as we tend to overbuild a bit.

Fuel and resource depot, construction facility, living area for 50 kerbals, storage of science for new bases. Need to expand it soon. 

[Lisias]

59 minutes ago, magnemoe said:

And yes physic is the real killer in KSP, more so as we tend to overbuild a bit.

Yep. but things does't needs to be this way forever.

Unity was born optimized to run on "high speed, fewer cores" paradigma. It relied mainly on co-routines for some parallelism.

Things changed. Currently, we are favoring "not so high speeds, but many cores" instead. You can get way more results on a 2GHz machine with 8 cores than from a machine with 2 cores running at 4GHz - as long you design your software accordingly.

Given the probable AMD dominance on the near future, the more cores/less speed paradigm should be taken seriously from now on.

How this can be applied to KSP? By, somehow, allowing big crafts to have their physics handled concurrently by more than one core. Nowadays (and unless something changed since the last time I was told about it), each craft is handled by only one core - so your biggest craft will determine your frame rate, not the quantity of CPUs available. This works better on a higher speed/lower cores paradigm - exactly what is being leaved behind nowadays.

Edited July 20, 2019 by Lisias
tyops! Who would thought of that? :P

[pmborg]

On 7/20/2019 at 12:09 AM, TimKerbin said:

This is just a rant about KSP's memory and GPU/CPU usage. How good/bad do you think it is?Can it be improved?

KSP isn't, by a long way, the most graphically taxing game out there. Compared to the kinds of graphics demands we see in other modern games - even on their lowest settings - the graphics demands in KSP are minimal by comparison, especially in vanilla. Which makes it so frustrating how this game can grind to a virtual halt just because you wanted to install one or two mods, or because you happened to have been playing for 5 hours straight. Even though my PC is at least 7 years old (2GB video RAM, 16GB of installed RAM,  an i7 multicore processor) it still more than meets the game's current MINIMUM specifications as set by Squad. The fact an old bucket like mine can still run this game fairly well, even with many mods installed, says it all. But do I sound like an entitled little gamer when I say that if I have 7GB of RAM available (as shown in Task Manager) I expect the damn thing to be able to access it, and it can't. Even in 64-bit! Or perhaps  this is still more of a Windows problem than a Unity problem? Or both?

I just get the feeling that KSP could and should be able to run at least 60fps even with many mods installed, and it's frustrating that it doesn't. Depending on the scene I can get maybe 24-30fps (in v 1.6.0), but that depends heavily on how busy the scene is. While docking with a moderately sized station it can drop to 9-12fps (I thought 1.6.0 was suppose to improve multicore rendering for multiple ships, but I really can't see any difference);  in maximum time warp I've seen it drop to 6fps and then shoot back up to 20 then back to 8. Indeed the framerate can be VERY inconsistent with frequent lag, and again I can't tell if it's my PC (toggling V-sync makes little difference, nor does setting a frame limit) , the mods, or the game engine. And please don't tell me to stick to vanilla; mods have defined this game just as they have defined SkyRim. Even Squad members themselves (Nova Silisco for example) contributed mods to this game. KSP just isn't appealing to me any more in vanilla, because I KNOW KSP can do so much better. The forums are always full of players suggesting or requesting new mods, especially visual enhancements, which says to me the community wants this game to be as good as it can be, and we really need to be asking if it is. Even after Unity5 and 64-bit mode were introduced.

I'm not a programmer but I can't help feeling that despite the move to Unity5 and its undoubted improvements, KSP still isn't running at its full potential; and it feels as if it never will as long as it's still using Unity. Programmers, mod-makers feel free to disagree.

My suggestion to Squad-Private Division: stop producing DLC and focus instead on continuing to improve how this game already uses available resources. No point in creating more 'stuff' for the game if in turn the game becomes so bloated and slow no-one can play it. No-one should need a StarCitizen-type setup to play this game satisfactorily, it ain't Star Citizen!

Hello Tim,

Please check my post on, about performance:

 

[panzer1b]

This game performs fine provided you dont overdo it on some of the more intensive mods (scatterer being my personal #1 performance hog, to the point ill actually disable it when i know ill have massive ships engaging each other at point blank range), and dont go totally insane with part count on ships.  The latter is really the problem, but it has little if any solutions to it without compromising the physics interactions (which are imo why KSP is such a amazing game, every component is physically modeled and can interact with each other component).

This is  battle between a 700 part count venator replica and a dimension (my own design), and the lag doesnt get too restricting imo.

The above providence has 0 framerate issues whatsoever despite being just over 500 parts with weapons onboard.  If you dont insist on loading 1000+ part vessels (which is the point on my machine where you start to feel the framerates), the game runs smooth enough to at least enjoy (with scattered disabled that is, with scatterer near atmo its far worse).  Due to multicore, ive found that if your processor has the cores, larger numbers of smaller vessels run fairly well too (4 300 part ships is quite manageable as well).

 

Anyways, if performance is killing you, start by cutting down complex mods, anything that would take up extra processing power to run while you play.  Culprits that come to mind is any visual fx, stuff with background processing (life support mods, resource drilling, ect), and anything that adds complex features to stock (good example would be KIS/KAS, interstellar, stuff that does something more then just add a new variety of parts).  As for part mods, those are relatively irrelevant solong as you dont exceed RAM limitations by using them, and some may even help you cut down lag if you like to build very large craft and can replace a stack of 2x2 panels with a single much larger panel.  Tweakscale is also a good way to save on lag since it lets you make larger ships without using as many things in them (i dont use it ,myself as its not my cup of tea but many do).

[magnemoe]

27 minutes ago, Lisias said:

Yep. but things does't needs to be this way forever.

Unity was born optimized to run on "high speed, fewer cores" paradigma. It relied mainly on co-routines for some parallelism.

Things changed. Currently, we are favoring "not so high speeds, but many cores" instead. You can get way more results on a 2GHz machine with 8 cores than from a machine with 2 cores running at 4GHz - as long you design your software accordingly.

Given the probable AMD dominance on the near future, the more cores/less speed paradigm should be taken seriously from now on.

How this can be applied to KSP? By, somehow, allowing big crafts to have their physics handled concurrently by more than one core. Nowadays (and unless something changed since the last time I was told about it), each craft is handled by only one core - so your biggest craft will determine your frame rate, not the quantity of CPUs available. This works better on a higher speed/lower cores paradigm - exactly what is being leaved behind nowadays.

I agree totally, clock speed has pretty much tapered off, all of the other tricks has strongly diminishing returns, more cores is the obvious solution to increased performance. 
But designing for loads of cores it pretty hard. 
However consoles has had 8 cores for an long time now. Hardcore PC users think that is  bit low. My 5 year old system has 6 cores and 12 treads at 4Gz, its predates throttling but has some serious water cooling  
Lived trough an time there I thought hot swap graphic cards was an issue, I needed to belt feed them, ironside hold up pretty well. Granted this is an 8 DIM server setup

[Motokid600]

If KSP 2.0 ever becomes a thing what would it take to support high performance at high part counts? Is it even possible given any game engine? Cant Simple Rockets 2 handle high part counts?

Edited July 21, 2019 by Motokid600

[micha]

17 minutes ago, Motokid600 said:

If KSP 2.0 ever becomes a thing what would it take to support high performance at high part counts? Is it even possible given any game engine? Cant Simple Rockets 2 handle high part counts?

Simple Rockets 2 doesn't have high part counts. As far as I can tell it effectively "welds" a rocket into a single part for flight mode. Even during construction you tweak parts to the sizes you need instead of lego-building your craft as in KSP keeping part counts low.

[Lisias]

2 hours ago, magnemoe said:

But designing for loads of cores it pretty hard. 
However consoles has had 8 cores for an long time now. Hardcore PC users think that is  bit low.

Very long. Sega Saturn abused that concept, mainly because it was designed over Sega's arcade mainboards. At that time, multiprocessing were the only way to extract all the juice they needed from the silicon.

About being hard.. yeah, it is. As anything that really does the job the best way it's possible.

ABS brakes. Automatic pilots. Space flight. Moon landings. Operating Systems. AAA Videogames. While the core business of the thing is inherently different, the software that does it share all the same concepts.

It's hard. But designing and building skycrapers and airplanes are too. And yet, we do it.

Things should be simple as possible - but rarely are easy or simplistic.

[JERONIMO]

7 hours ago, linuxgurugamer said:

Then you would need infinite memory.  It’s the nature of the language, in fact, most modern languages have it in one for or another

did i mention that i play on low graphics?

[linuxgurugamer]

6 hours ago, JERONIMO said:

did i mention that i play on low graphics?

With KSP, it's  the CPU that is is the limiting factor

Edited July 21, 2019 by linuxgurugamer

[cantab]

12 hours ago, Lisias said:

To tell you the true… There's a memory management approach that I think it could be used to get an acceptable common ground. Mark and Sweep (Mark and Release for old farts that used to program in Pascal or Modula).

I can't say as much about the technical details, but I do know that newer versions of Mono (since 2017) can avoid the "stop the world" garbage collection. Some other C# runtimes also avoid it. But again, we're back to decisions taking years ago - in this case, things Unity did that means they can't easily upgrade to the new Mono. (In fact if I remember rightly Unity are planning to switch to .Net Core.)

So basically, KSP's problems are because of unresolved technical debt.

[Lisias]

3 hours ago, cantab said:

I can't say as much about the technical details, but I do know that newer versions of Mono (since 2017) can avoid the "stop the world" garbage collection. Some other C# runtimes also avoid it. But again, we're back to decisions taking years ago - in this case, things Unity did that means they can't easily upgrade to the new Mono. (In fact if I remember rightly Unity are planning to switch to .Net Core.)

Asynchronous and Concurrent Garbage Collection is a terribly complicated and convoluted code. And it makes things even less predictable. Java has G1 since many years ago, and yet high performance video-games avoid the runtime.

It's interesting to see people telling that C# will solve things by using solutions from Java, which people says is unsuitable to the problem.

Forget anything they told you - every single feature of the C# runtime that is being promised or even delivered was already implemented in Java in the last 10 years - some more than 10 years. And yet, Java is not the first choice for most game development.  

 

3 hours ago, cantab said:

So basically, KSP's problems are because of unresolved technical debt.

Technical debts deeply buried in the design of the runtime. There's no other way to go, people need to acknowledge the limitations of the technology and work around it. Waiting for others to fix the mess is rarely (if ever) a proper solution for a problem.

[Guest]

17 hours ago, Motokid600 said:

If KSP 2.0 ever becomes a thing what would it take to support high performance at high part counts? Is it even possible given any game engine? Cant Simple Rockets 2 handle high part counts?

Dynamic autowelding to a reasonable physics part count ceiling would do it. Other possible optimisations would be to treat other than the focused vessel as a single part or remove landed/parked vessels from physics altogether, unless/until something collides with them. 

The trade-off would be a stutter when the autowelds are recalculated (e.g. on collision or on un/dock), and somewhat less accurate simulation of things coming apart. 

The garbage collection issue ought to be resolvable -- but it might be buried so deep in Unity that in practice the effort to do so is prohibitive.

A genuine fix to KSP's performance problems would likely be a lot of work and involve a major engine upgrade (or switch to a different one altogether). That would be very expensive; I don't think it could be done without massively expanding the player base or somehow getting us to pay for the game again -- and given the unhappiness about paid DLC I doubt that's on the cards either.

Edited July 21, 2019 by Guest