Ksp need to fix the performance

[Archgeek]

Hmm, it seems we're starting to talk past each other a bit.  It remains true that there's little that can be done about high-part-count ships slowing things down due to the absurd complexity of the problem (technically you can parallelize the mess in question, but non-parallelizable means it can't be parallelized and see detectable gains--indeed it's very possible to see negative gains due to increased overhead), but @invision, your problem sounds more like either your box or KSP's GC is doing something dumb.  I'd pin it on a mod doing something dumb, but you say it's in stock (what version?  Does it do it in the version before that, or before that?)  For that matter, what's your disc access get up to when this happens?

I know my game gradually gets near to unplayable due to some slight memory leak and my 10yr-old box having only 4 gigs of RAM (starts paging my browsers and and other things off to disk, slowing down the game to do so because dual-core isn't enough, crap help me if I alt-tab), but that takes hours and hours, like 6+.

Upshot: KSP's main bottleneck was and still is raw single-core clock speed (it's gotten a little more complex than that, but not enough to make a difference at scale).  A 3.1GHz Core 2 Duo will outperform a 2.2GHz i5 octo-core, and any thing chunkier than a Radeon 9k is almost pointless for graphics.  Flotillias beat motherships, since that lets the game give things seperate threads for once, and I suspect you've encountered a bug which you may want to carefully reproduce in a clean install and report to the devs so they can squash it.

[invision]

4 hours ago, Archgeek said:

Hmm, it seems we're starting to talk past each other a bit.  It remains true that there's little that can be done about high-part-count ships slowing things down due to the absurd complexity of the problem (technically you can parallelize the mess in question, but non-parallelizable means it can't be parallelized and see detectable gains--indeed it's very possible to see negative gains due to increased overhead), but @invision, your problem sounds more like either your box or KSP's GC is doing something dumb.  I'd pin it on a mod doing something dumb, but you say it's in stock (what version?  Does it do it in the version before that, or before that?)  For that matter, what's your disc access get up to when this happens?

I know my game gradually gets near to unplayable due to some slight memory leak and my 10yr-old box having only 4 gigs of RAM (starts paging my browsers and and other things off to disk, slowing down the game to do so because dual-core isn't enough, crap help me if I alt-tab), but that takes hours and hours, like 6+.

Upshot: KSP's main bottleneck was and still is raw single-core clock speed (it's gotten a little more complex than that, but not enough to make a difference at scale).  A 3.1GHz Core 2 Duo will outperform a 2.2GHz i5 octo-core, and any thing chunkier than a Radeon 9k is almost pointless for graphics.  Flotillias beat motherships, since that lets the game give things seperate threads for once, and I suspect you've encountered a bug which you may want to carefully reproduce in a clean install and report to the devs so they can squash it.

the screen shots were from a modded game but the same thing happens in stock.

my mods are part mods with a light version of EVE for cloud textures, it doesnt hamper the performance as i lose maybe 5 fps from the mod on or off.

[Greenfire32]

On 2/8/2018 at 1:58 PM, invision said:

theres no reason my game should run at 20 frames a second with a Ryzen 5 1600 which is overclocked to 3.9ghz and paired with a GTX 1080, but it does happen and it happens a lot especially if the mission is very long.

 

 

On 2/8/2018 at 2:44 PM, invision said:

simply hanging out on the surface of the moon shouldnt run the game at 20 fps

going to space center and then reloading the same ship now the game runs at 100 fps

there is nothing to calculate except bad coding.

 

I have a pretty beefy machine (though not quite as beefy as yours) and it outperforms your claims by miles. If your game is behaving that badly, it's something on your end.

How big is your craft? Massive ships or ships with tons and tons and tons of parts or ships withing range of other ships (or bases) with tons of parts will cause performance drain.

How many mods you got? Vanilla KSP will always always always outperform modded KSP. Even if you "only" have just a few.

Are you multi-tasking? If you're anything like me, you've got 3 monitors and they're all doing something. Don't do this with KSP, it doesn't work very well at all. KSP time is KSP time.

Lastly, is everything plugged in and working correctly? I had a friend who built a PC once and was getting constant low FPS (we're talking like 5-20) and it was only on certain games. Turns out, bad CPU cooler. Too hot to run efficiently, not hot enough to trigger an emergency shutdown.
--------
KSP does not run very well when compared to the rest of the gaming universe, but it definitely should not be behaving like that on a system like yours unless something on your end is causing it. That said...yes, I would love some better performance in KSP.

[invision]

5 minutes ago, Greenfire32 said:

 

I have a pretty beefy machine (though not quite as beefy as yours) and it outperforms your claims by miles. If your game is behaving that badly, it's something on your end.

How big is your craft? Massive ships or ships with tons and tons and tons of parts or ships withing range of other ships (or bases) with tons of parts will cause performance drain.

How many mods you got? Vanilla KSP will always always always outperform modded KSP. Even if you "only" have just a few.

Are you multi-tasking? If you're anything like me, you've got 3 monitors and they're all doing something. Don't do this with KSP, it doesn't work very well at all. KSP time is KSP time.

Lastly, is everything plugged in and working correctly? I had a friend who built a PC once and was getting constant low FPS (we're talking like 5-20) and it was only on certain games. Turns out, bad CPU cooler. Too hot to run efficiently, not hot enough to trigger an emergency shutdown.
--------
KSP does not run very well when compared to the rest of the gaming universe, but it definitely should not be behaving like that on a system like yours unless something on your end is causing it. That said...yes, I would love some better performance in KSP.

single monitor maybe 1 tab open for internet, 20 mods mainly parts mods and the ship in question i believe was about 100 parts/

this is the only game that has issues, any other game i can run maxed out with 120+ fps so its not the pc.

the pc is also only used for gaming and youtube it does nothing else.

ive found a work around of simply reloading the craft mid play so its not a life or death fix its just odd it even happens.

im waiting till 1.4 to release and ill see if anything gets better from there or not.

Edited February 12, 2018 by invision

[Greenfire32]

20 minutes ago, invision said:

single monitor maybe 1 tab open for internet, 20 mods mainly parts mods and the ship in question i believe was about 100 parts/

this is the only game that has issues, any other game i can run maxed out with 120+ fps so its not the pc.

the pc is also only used for gaming and youtube it does nothing else.

ive found a work around of simply reloading the craft mid play so its not a life or death fix its just odd it even happens.

im waiting till 1.4 to release and ill see if anything gets better from there or not.

based off this, I would check your mods. This does indeed sound like a case of mods either not playing nice together, not updated, not compatible, or just being heavy resource hogs.

[linuxgurugamer]

Start off by posting a link to the log file,  along with a list of tthe mods you have installed.  It's  quite  possible that someone here on the forums will see something in the logs which will help you.

[harrisjosh2711]

I thought I would leave it up to the professionals as I have always thought something was going wrong in the coding in KSP. This is for the console version which I feel is even more relevant as generally console games are ported to run efficiently on systems unlike computers where hardware varies so widely a single optimization cant be made. "The framerate is also wildly inconsistent, especially when performing manoeuvres in space – even in the zoomed-out map screen the framerate slows down noticeably upon turning on the throttle, and with particularly complex ships the game struggles even on the launchpad. Sure, the physics engine must use up a lot of the PS4’s power, but these constant slowdowns are surprising considering that its graphics are very basic: the surface of most planets look very low-res even from far away, and the admittedly-cute Kerbals are in need of some anti-aliasing with all of their jagged edges."

http://www.pushsquare.com/reviews/ps4/kerbal_space_program_enhanced_edition

Lets just be honest. KSP was made by a small studio who obviously didn't have the most experienced coders in the world.

Edited February 12, 2018 by harrisjosh2711

[drhay53]

Let's just be honest, the people who posted that review and the quote you picked out assume that the GPU has anything to do with the framerate of KSP.

Edited February 13, 2018 by drhay53

[drhay53]

I am pretty sure the the OP has no actual interest in debugging what is happening, although I'll be pleasantly surprised if I'm wrong. "The same thing happens in stock" is repeated so many times that it's fairly clear to me that no rigorous attempt at testing has actually been done.

[Starman4308]

3 hours ago, harrisjosh2711 said:

I thought I would leave it up to the professionals as I have always thought something was going wrong in the coding in KSP. This is for the console version which I feel is even more relevant as generally console games are ported to run efficiently on systems unlike computers where hardware varies so widely a single optimization cant be made. "The framerate is also wildly inconsistent, especially when performing manoeuvres in space – even in the zoomed-out map screen the framerate slows down noticeably upon turning on the throttle, and with particularly complex ships the game struggles even on the launchpad. Sure, the physics engine must use up a lot of the PS4’s power, but these constant slowdowns are surprising considering that its graphics are very basic: the surface of most planets look very low-res even from far away, and the admittedly-cute Kerbals are in need of some anti-aliasing with all of their jagged edges."

http://www.pushsquare.com/reviews/ps4/kerbal_space_program_enhanced_edition

Lets just be honest. KSP was made by a small studio who obviously didn't have the most experienced coders in the world.

I can't speak for the bugginess, but that comment suggests the reviewer has a poor understanding of computer science and the subtleties that differentiate KSP from most video games from a computer science perspective.

The PS4 does not have "power". It has 8 Jaguar cores clocked at 1.6 GHz and 1152 GCN graphics cores clocked at 800 MHz, along with 8 GB of GDDR5 memory. These cores do not Voltron into a mega-core. They do not have a magic wand to magically separate compute problems into numerous compute threads. They do not drive a common shaft to propel a vehicle. They do not combine their spirits to more quickly draw memory out of RAM. They do not benefit from the power of friendship.

They execute streams of instructions assigned to them, and if the programmer can't figure out how to efficiently split the problem at hand into multiple instruction streams, you're stuck running on a single 1.6 GHz CPU. This is not necessarily because the programmer is inexperienced, but can potentially just be because it's not a problem that lends itself to being split up.

 

Let's take a space-related example: predicting the trajectories of maybe 5 planets over time. For now, I'll ignore parallelization overhead issues that would make this example really stupid to try to parallelize.

You can split that up to some extent. You can assign one thread to each of five planets, that figures out what the force of gravity is from each of the other 4 planets. Instead of one core doing 20 force evaluations, you can have 5 cores doing 4 evaluations per timestep. Ideally, this is a 5x speedup.

You can split it up even further: 20 threads, one for each pair of planets (though, really, there are just 10 pairs, but both ends of each pair need the distance). You're at 20x speedup.

That's the limit for this problem. In order to calculate the forces of gravity at timestep n+1, you must first have the positions at timestep n. You can't try to do timestep n+1 and n at the same time, because n+1 is dependent on timestep n. This means you have to take timesteps sequentially. There is no point to trying to assign 40, or 400, or 40 million cores to the problem, because you can only split the work up into 20 threads.

 

Rigid-body physics happens to be one of these types of problem where it's really hard to efficiently break it up into multiple chunks of work. Not only that, but each time you try to parallelize something, there's a good chance you make a mistake and introduce a bug that produces incorrect results (this has happened in my lab, multiple times!). Programming a single-threaded rigid-body physics engine is enough of a challenge; attempting efficient parallelization under arbitrary geometries is not a task you should expect a small, indie game studio to handle.

[harrisjosh2711]

@Starman4308 very good explanation. I meant to say something about the uniqueness of ksp. I understand that this isn’t something that has exactly been done before, the only thing that comes even close I can think of is flight simulator. Ksp is without a doubt a tremendous accomplishment, that goes without saying. I guess a good way to express my thoughts is move the studio Into a fully industrialized country and give development of ksp over to someone like Elon Musk and let’s watch what happens to it. Word I heard is squad pays 2400 a year. You sir seem like a highly gifted and educated individual. Would you go work that? The conclusion I came to was there was a lack of talent at squad. Because I’m just an amateur modeler and I couldn’t work for that lol.

[Starman4308]

12 minutes ago, harrisjosh2711 said:

@Starman4308 very good explanation. I meant to say something about the uniqueness of ksp. I understand that this isn’t something that has exactly been done before, the only thing that comes even close I can think of is flight simulator. Ksp is without a doubt a tremendous accomplishment, that goes without saying. I guess a good way to express my thoughts is move the studio Into a fully industrialized country and give development of ksp over to someone like Elon Musk and let’s watch what happens to it. Word I heard is squad pays 2400 a year. You sir seem like a highly gifted and educated individual. Would you go work that? The conclusion I came to was there was a lack of talent at squad. Because I’m just an amateur modeler and I couldn’t work for that lol.

It's not necessarily so much a lack of talent, so much as that the talent doesn't have millions of dollars to sink into an R&D project to develop a high-performance rigid-body physics engine capable of handling all the weird geometries KSP players throw at it, plus more money to test it until it's ready for commercial gameplay release.

With time and effort, the programmers at Squad might do it. Unfortunately, optimizing the game engine is not something that would pull in enough new customers to justify a multimillion-dollar coding project.

Probably the biggest reason Squad chose to go with Unity at the outset was that Unity already had a tested rigid-body physics engine. That logic hasn't changed: it would still be more effort than it's worth for Squad to try to parallelize the physics engine.

[SnailsAttack]

I wish they'd just include more part "bundles". Throw all the different science types into one computer-type thing that can record an unlimited number of experiments or add larger, longer fuel tanks or even just make ships not require a thousand struts to hold together during launch.

[Blaarkies]

1 hour ago, SnailsAttack said:

or even just make ships not require a thousand struts to hold together during launch.

main menu > settings > advanced tweakables
In editor mode, right click a part, toggle auto-strut

[cfds]

4 hours ago, Starman4308 said:

Probably the biggest reason Squad chose to go with Unity at the outset was that Unity already had a tested rigid-body physics engine. That logic hasn't changed: it would still be more effort than it's worth for Squad to try to parallelize the physics engine.

Well, the obvious solution would be to drop the chained rigid body simulation altogether and treat vessels as monolithic blocks. In most use cases there is a pushing engine at the back and inertial mass at the front and no need whatsoever to simulate bending, twisting or compression. You could still compute some kind of differential forces to special parts (decouplers, docking nodes) to test for breaking but you would massively reduce the number of constraints...

[Guest]

7 hours ago, Starman4308 said:

Rigid-body physics happens to be one of these types of problem where it's really hard to efficiently break it up into multiple chunks of work.

It ought to be possible to parallelise physics calculations for different craft at least. You would need an algorithm that's able to test whether they're interacting or likely to interact in the immediate future, and move the calculations to the same thread if necessary, but that shouldn't be too difficult, even with fairly dumb heuristics. It ought to also be possible to exclude craft from rigid-body physics calculations if there are no forces acting on them, or (special case) they're resting on the ground motionless.

This alone would solve most of my most irksome performance problems at least: I'm only really hitting serious issues on off-world bases which have several craft on them, even if most of them are sitting on the ground doing nothing.

[Archgeek]

7 hours ago, Brikoleur said:

It ought to be possible to parallelise physics calculations for different craft at least. You would need an algorithm that's able to test whether they're interacting or likely to interact in the immediate future, and move the calculations to the same thread if necessary, but that shouldn't be too difficult, even with fairly dumb heuristics.

[...]

It ought to also be possible to exclude craft from rigid-body physics calculations if there are no forces acting on them, or (special case) they're resting on the ground motionless.

Oh, it is and they do.  Ever since they got an official 64b version that worked, they've had multiple craft in the same physics bubble on their own threads.  That's why I said flotillias are superior to motherships -- assuming the problem's roughly O(n^2), 8 n-part ships will run a lot better than 1 8n part ship, by a factor of 64 (minus overhead, 16.6 minus overhead if it's n*ln(n)).  In fact, you may sometimes notice an odd bit of lag during a major staging event -- that didn't used to be there.  It is in fact a brief pause while the game re-divides the parts in the scene into several new trees for the "vessels" produced by detaching those boosters and/or droptanks and assigns them to new threads.

[...]

That they don't do.  If they did, we'd never've had landers creeping uphill in gradual, unsettling fashion.

[Shadowmage]

 

7 hours ago, Brikoleur said:

This alone would solve most of my most irksome performance problems at least: I'm only really hitting serious issues on off-world bases which have several craft on them, even if most of them are sitting on the ground doing nothing.

This is actually -caused- by KSP code.

Unity Rigidbody phsyics (PhysX) has code in place to test if a rigidbody has not received any force inputs recently and will then put that rigidbody 'to rest', which disables its phsyics updates until it receives an external force.  I believe this even works with sets of joint-constrained rigidbodies (e.g. vessels made up of parts in KSP).

Now, the problem actually stems from KSPs manual application of gravity.  Anytime that a force is applied to a rigidbody, it 'wakes up' (or resets the rest counter).

Combine #1 and #2... and you get rigidbodies that -would- go to rest while sitting on a planet surface, except KSP has had to manually apply gravity (likely using rigidbody.addForce or similar), which then wakes up/prevents resting of the rigidbodies in the vessel.  (technically this should be able to be expanded upon, so that even vessels -in orbit- would be 'resting' when not have external forces exerted on them)

So as long as KSP has to manually apply gravity... it is a non-solvable situation.  And Unity was never designed to simulate a full 3d newtonian system, so expecting them to make changes to account for arbitrary gravity vectors is pointless and futile (actually you -can- specify a manual gravity vector in Unity engine, but I'm not sure how smooth it is to update, and I think the actual problem was the timing of when it was applied would mess with the rest of physics integration while in orbit; e.g. the gravity applied by Unity was not correctly integrated into the rest of the orbital simulation).

[suicidejunkie]

12 hours ago, Blaarkies said:

main menu > settings > advanced tweakables
In editor mode, right click a part, toggle auto-strut

Or simply stack the parts neatly, don't worry about a wee bit of flex, and avoid amplifying your oscillations with inappropriate SAS/control outputs?

I've jackknifed a skylab on the way up, and had my share of RUDs, but they were my own fault for poor design and/or piloting, and I don't want to blame the game for it or turn off physics elements to make it work anyways.

If you don't care about the engineering and just want to fly a fun looking assemblage into space, that's totally cool; I've made my share of crazy contraptions, but the game clearly does not require struts to make ships work if you do things right.

[Rocket Farmer]

On 2018-02-08 at 6:32 PM, Starman4308 said:

“and if a smoothbore round began to tumble, that would have a huge effect on ballistic coefficient”

Actually all bullets fired above the speed of sound traveling through atmosphere will eventually tumble (end over end) if they don’t hit something first.  Proper rifling will only hold for so long as the bullet slows down and the aerodynamics involved change.

 

When shooting at 2,500+ yards with modern shells I have seen bullets strike the target sideways a couple of times (meaning they just started to tumble right before the target).  For the first 2,000+ yards they will fly fine until suddenly starting to cartwheel.  Hot loading, match shells etc only get you so far (humidity is typically a bigger factor).  

This type of physics (sans the humidity) would be properly rendered in KSP but not in any of those shooter games.

W

[Starman4308]

32 minutes ago, Rocket Farmer said:

Actually all bullets fired above the speed of sound traveling through atmosphere will eventually tumble (end over end) if they don’t hit something first.  Proper rifling will only hold for so long as the bullet slows down and the aerodynamics involved change.

 

When shooting at 2,500+ yards with modern shells I have seen bullets strike the target sideways a couple of times (meaning they just started to tumble right before the target).  For the first 2,000+ yards they will fly fine until suddenly starting to cartwheel.  Hot loading, match shells etc only get you so far (humidity is typically a bigger factor).  

This type of physics (sans the humidity) would be properly rendered in KSP but not in any of those shooter games.

As you can probably tell, I'm not a sharpshooter. I went out shooting once with my uncle, and it was kinda fun, but hitting the target at 10 yards does not exactly make me a sharpshooter or ballistics expert.

Regardless, for most games, it's not an issue. Call of Duty and many other popular shooters occur at such short range I'm not even sure drag is relevant, and certainly not long-range tumbling effects. Something like the ARMA series might want to model it out of utter dedication to simulation realism (as I understand, ARMA is the Realism Overhaul of first-person shooters).

However, even then, you're probably looking at pre-computing ballistics under a variety of conditions, and then using lookup tables or curves, rather than trying to do computational fluid dynamics on the fly for every bullet in the air. Even hardcore simulation players generally accept some compromise in the name of performance.

[Blaarkies]

9 hours ago, suicidejunkie said:

If you don't care about the engineering and just want to fly a fun looking assemblage into space, that's totally cool; I've made my share of crazy contraptions, but the game clearly does not require struts to make ships work if you do things right.

Smooth, simple, small ships yes. Massive payloads on rockets that use Mammoth engines as side boosters? No

Players want to build BFR-like rockets, but with only stock parts one needs a bit of creativity. Auto-strut was added as a quick-fix because even the devs agreed that the wobbling is just too much

[Guest]

There are other simplifications/optimisations they could do, which would affect the accuracy of the simulation but I think would have negligible gameplay effects. For example, they could group parts into units which are then treated as a single object in terms of physics. Candidates would include payloads inside fairings, wing surfaces, and stacks of small parts.

For example, they could make it so that a stack or a wing surface always has 1-4 parts. Any parts above that are merged into larger parts. The components making up the group determine the thermal and physical stress thresholds for it. If exceeded, it flies apart from random locations in a big kaboom.

This wouldn't be as accurate as the current simulation, but I think in practice the results would be close enough that most of the time you wouldn't notice any difference (and when you would, it would be an improvement -- big wing surfaces wouldn't flap around like they do now unless autostrutted, and noodle rockets would be somewhat less noodly). 

This approach should address the scaling problem, as it would cap the number of parts used in the physics calculations, regardless of what went into the ship.

If they were feeling nice about it, they could even give players a measure of control over which parts make a group.

Edited February 14, 2018 by Guest

[Dafni]

19 hours ago, Shadowmage said:

 

And Unity was never designed to simulate a full 3d newtonian system...

Hmm, interesting. Makes you wonder why they picked that engine in the first place. Are there better alternatives at all then??

 

@Shadowmage thank you for your informative post. Nice way of explaining it. Up until now I did not know some of the facts you explained, and the thing about manually applied gravity now explains a lot for me. Thank you again.

[Guest]

32 minutes ago, Dafni said:

Makes you wonder why they picked that engine in the first place.

It's cheap.

Back when KSP was started, it was if not the only game in town at that price point, at least pretty close to it. Things are a bit different now, but back then there really weren't many other options.