Performance is still not good with ships that have many parts

[Jason_25]

I have just finished several hours of testing today to see why I have been getting such bad performance.  Instead of posting all my testing results here which would just confuse things I will just post my conclusions.  My gaming system has an i7 6700K/32 GB RAM/Radeon 6800 16GB.  Linux kernel version 6.5.0-0.  Performance was similar on Windows 10.

I wanted to preface this by saying this is for gaming systems only not mobile devices that are constricted by hardware and run other games slow too.  My system only runs this game slow.  Every other game is super fast.  So tweaks can still help slower systems.  On to the results.

214 part test vehicle has 23 FPS on runway.

89 part control vehicle has 49 FPS on runway.

There is no difference in FPS without the launcher and on a "clean slate" and a well used installation with the launcher.

There is no difference in FPS between 720p and 4K resolutions.

There is no difference in FPS between all low and all high graphics.

There is no difference in FPS between all Proton versions available on Steam.

There is no difference in FPS between default and the launch switch -screen-quality Fastest or with --screen-quality Fastest.

There is no difference in FPS between environment variables listed on the KSP 2 and Proton thread except WINED3D which is slower.

We can see that there is a pretty linear decrease in FPS with more parts.  It throws a wrench into the interstellar plans for sure and for people like myself that like to build big and comfortable and safe ships.  I think that for too long we have been leaning on the rocket equation as the crutch for why large ships are not or should not be built.  But there are "bigger" things to consider like aircraft carriers, colonies, generation ships, O'Neill Cylinders, and highly efficient Sci-Fi vehicles that defy the rocket equation.

Some people think that we will have single parts that will be very large that will make large vehicles a reality but we need that now.  Something like procedural fuselages and fuel tanks.  Or they can take an honest look at the problem another way and figure out why a game with cartoon graphics is having such bad performance.  It cannot just be the physics that is slowing the game down.  We had exploding body physics in games back in the 90s like Unreal Tournament or moving physics objects like in Jurassic Park Trespasser.  There has to be some major major problems with the game code somewhere.

[magnemoe]

How do you see how many part your ship has, launched my first interplanetary one and it climbed slowly, now I was also confused because the dV reading as first time I used cross-feed in KSP 2 so I assume twr was horrible, but I dropped the 4 liquid fulled boosters just before reaching space and had more dV in core than expected, still it boosters was just 25 parts + struts. Ship works well in deep space, 
Saw some heating inside fairing who might be part of the problem. 

Edited February 5 by magnemoe

[HebaruSan]

52 minutes ago, Jason_25 said:

214 part test vehicle has 23 FPS on runway.

89 part control vehicle has 49 FPS on runway.

[...]

We can see that there is a pretty linear decrease in FPS with more parts.

Can we? You've only presented two data points. Two points could represent a line, but they can just as easily be quadratic, exponential, logarithmic, or some other more obscure pattern.

Edited February 4 by HebaruSan

[Oak7603]

What do you mean by I wanted to preface this by saying this is for gaming systems only not mobile devices that are constricted by hardware and run other games slow too? KSP2 doesn't run on any mobile devices does it?

[Bej Kerman]

15 hours ago, Jason_25 said:

We can see that there is a pretty linear decrease in FPS with more parts.

[cocoscacao]

17 hours ago, Jason_25 said:

Something like procedural fuselages and fuel tanks

This was such an obvious step, but I don't think it will ever happen....

[magnemoe]

2 hours ago, cocoscacao said:

This was such an obvious step, but I don't think it will ever happen....

Wonder if atmosphere has more to do with it? the orbital rocket itself is just an faction of the parts. say 30 out of 260, add 10 struts. rest is the transfer craft and 3 landers and a rover. 
But launch was slow. 5 mainsails, 4 side boosters and core with crossfeed, once this was dropped ship behinds smoothly, even the high power burn with the core mainsail. 

Edited February 5 by magnemoe

[pschlik]

Back in October at the Space Creator Day, the For Science! announcement presentation showcased some really good performance improvements with "SimTransform" and as far as I can tell that just...didn't happen? I can understand if there's more work to be done, and I certainly don't think the whole multicore physics thing is vital for the current state of the game, but it would be very useful. The combination of poor single vessel performance and vessels taking up CPU time even in the background meant that I had to scrap a mission to Dres until after completing my Moho mission. Performance is bad enough with just one big interplanetary vessel, having two in existence just makes everything so much slower, even the tiniest probe.

But I can work around it (by spending time building a mission then immediately returning the crew to Kerbin yayyyy), even if it is frustrating that my 5800X3D and 3080ti just sit there at like 1/3 utilization. Though it could be worse, at least there seems to be a plan(?) for KSP 2 to learn how to use more of the CPU. We could be playing Cities: Skylines 2, which will peg the GPU and every CPU to 100% utilization and still somehow be unable to run its simulation faster than 2x speed while barely touching 60 fps, and there's not a whisper of any tech that will improve CS2 performance by a factor of 2.

Hopefully colonies will put pressure on the team to reduce the processing time of background vessels and to finish up multicore processing. KSP2 won't remain playable for long without it.

[Scarecrow71]

1 hour ago, magnemoe said:

Wonder if atmosphere has more to do with it? the orbital rocket itself is just an faction of the parts. say 30 out of 260, add 10 struts. rest is the transfer craft and 3 landers and a rover. 
But launch was slow. 5 mainsails, 4 side boosters and core with crossfeed, once this was dropped ship behinds smoothly, even the high power burn with the core mainsail. 

It isn't so much the atmosphere as it is the planet/ground.  That has been known to cause issues with FPS upon launch (and even descent).  Only workaround at the moment is to point the camera to where it isn't looking at the ground at all...which is a shame because the terrain is beautiful.

[magnemoe]

1 hour ago, Scarecrow71 said:

It isn't so much the atmosphere as it is the planet/ground.  That has been known to cause issues with FPS upon launch (and even descent).  Only workaround at the moment is to point the camera to where it isn't looking at the ground at all...which is a shame because the terrain is beautiful.

Now this makes some sense and thank for the advice. Now I don't need to look at terrain then launching huge interplanetary crafts, planes are better for that  

[Audaylon]

The current version of the game can handle 4 giant independant moving objects AND an airplane on the runway at 12 fps, without crashing!  Its getting better. 

[Spicat]

3 hours ago, magnemoe said:

Wonder if atmosphere has more to do with it? the orbital rocket itself is just an faction of the parts. say 30 out of 260, add 10 struts. rest is the transfer craft and 3 landers and a rover. 
But launch was slow. 5 mainsails, 4 side boosters and core with crossfeed, once this was dropped ship behinds smoothly, even the high power burn with the core mainsail. 

A lot of people are forgetting about this but fuel flow is pretty bad right now.

More active engines is much worse than the equivalent in parts. Same for the amount of tanks those engines are draining.

That’s why when you drop engines (and tanks), it’s a lot better, not really due to the atmosphere.

They really have to optimize all of this for colonies and interstellar.

Edited February 5 by Spicat

[kdaviper]

2 hours ago, Scarecrow71 said:

It isn't so much the atmosphere as it is the planet/ground.  That has been known to cause issues with FPS upon launch (and even descent).  Only workaround at the moment is to point the camera to where it isn't looking at the ground at all...which is a shame because the terrain is beautiful.

You get to look at the ground? Most of my time is in map view lol. Reentry is usually the only time I get to actually look at Kerbin( up close at least)

[Jason_25]

On 2/5/2024 at 4:29 AM, Oak7603 said:

What do you mean by I wanted to preface this by saying this is for gaming systems only not mobile devices that are constricted by hardware and run other games slow too? KSP2 doesn't run on any mobile devices does it?

Steam deck and laptops are mobile systems.  My Mobile Internet Device project is like a smartphone but will run KSP 1 just fine.  Part of the reason for this post is I would like to see KSP 2 running on one of my future Mobile Internet Devices.  But the point was these mobile systems are going to be self-limited and can still benefit from tweaks here or there whereas larger systems are limited by the game code itself or relegated to needing hardware upgrades.

22 hours ago, Spicat said:

A lot of people are forgetting about this but fuel flow is pretty bad right now.

More active engines is much worse than the equivalent in parts. Same for the amount of tanks those engines are draining.

That’s why when you drop engines (and tanks), it’s a lot better, not really due to the atmosphere.

I think this is why my Durandal Excalibur cruiser runs so bad.  It has countless fuel tanks.  I wanted to fill all the otherwise useless fuselage space with hydrogen.  It Is the "test" vehicle mentioned in this thread and the "control" vehicle is VTOL Quebec.  Both can be seen in this mission report:

Thanks for all the replies.

[magnemoe]

23 hours ago, Spicat said:

A lot of people are forgetting about this but fuel flow is pretty bad right now.

More active engines is much worse than the equivalent in parts. Same for the amount of tanks those engines are draining.

That’s why when you drop engines (and tanks), it’s a lot better, not really due to the atmosphere.

They really have to optimize all of this for colonies and interstellar.

Yes, I made my two first large interplanetary craft Moho and Duna. It has two long 2.5 meter hydrogen tanks and two shorts who hold the engines. then has 2x2 long drop tanks added with symmetry, decopler, tank, tank below fuel pipe and strut at bottom. Moho ship behaves well, Duna one only drain on one side, so it started spinning while I was AFK messing up the burn. 
Not comfortable with warp under burn for large ships. 
Ships are identical but the Duna one has more none related pats as in the Duna lander. 

This might me rethink the 16 tanks and two nuclear engine Duna followup ship in VAB, doubt the first ship has enough dV to get home and the new one has lander with radiation measurement and an orbital lab. 
Now this problem will get smaller as I unlock the large nuclear engine and the huge hydrogen tanks. 

One idea might be to treat items inside an sealed cargo bay or fairing as one object until opened. Sealed as you can use cargo bays for other stuff. 

Edited February 6 by magnemoe

[Brofessional]

On 2/4/2024 at 12:45 PM, Jason_25 said:

My gaming system has an i7 6700K/32 GB RAM/Radeon 6800 16GB.

i7 6700k is 8+ years old now, getting quite dated.

As long as KSP2 is using Unity/PhysX there isn't going to be any breakthrough in part-count performance though. They can reduce the number of physics calculations going on by "welding" parts, but the tradeoff there is simulation accuracy.  The tricky part is doing that in a way that "just works" behind the scenes and doesn't conflict with what the player is trying to accomplish at any given moment.

[Jason_25]

22 hours ago, Brofessional said:

i7 6700k is 8+ years old now, getting quite dated.

I just tried overclocking from 4 ghz to 4.4 ghz on CPU core and cache.  I also used the Linux cpupower utility to set the performance governor for the CPU.  This is a 10% overclock so we would expect as much as a 2 FPS gain or so but FPS was still no more than 23 steady but it did briefly blip to 24.  The bottleneck is all inside the game code itself.  Games like Starfield and Cyberpunk 2077 and Mechwarrior 5 all run very fast at 4K on this system.  On basically every other game you can see all the CPU cores near max usage but this game uses about 20% on all the CPUs and occasionally maxes out one CPU for a split second then goes back to basically doing nothing.  So I am afraid I could go through all the trouble to build a new system only to get about 25 FPS max with the way I build ships.

[rogerawong]

1 hour ago, Jason_25 said:

This game uses about 20% on all the CPUs and occasionally maxes out one CPU for a split second then goes back to basically doing nothing.

23 hours ago, Brofessional said:

As long as KSP2 is using Unity/PhysX there isn't going to be any breakthrough in part-count performance though.

Half true.

Generally speaking, apps made with Unity depend heavily on a single thread called MonoBehavior. Being a single thread, it can only run on one CPU core, regardless of how many cores the CPU has. 

It's up to the developer to re-architect their code to move functions out of MonoBehavior in a way that they can have different parts of the game loop running in separate concurrent threads distributed amongst the available CPU cores. 

At some point they're going to have to optimize to run on multiple cores. It appears they just aren't fully there yet as far as KSP2 is concerned.

But it makes sense though. You want to be sure you've nailed the main game loop before investing heavily into optimizing or recoding because you don't want to have to discard that effort if it turns out you need to make more changes to your core game loop to satisfy some newly-discovered need.

Edited February 7 by rogerawong

[steveman0]

Rearchitecting something as critical as the threaded architecture of the game is not something I would ever suggest. I would hope they planned these requirements out early on if there was going to be any migration to a new threading design. It can be a nightmare to take single-threaded code and rework it to be threadsafe and communicated across thread boundaries.

In Unity's case, the less graphical/GameObject-specific code you run on the main thread, the better. I would hope (without having looked into anything theu've done so far) that they already leverage threads for any work not intrinsically linked with GO manipulation. Simulation math is ideally offloaded to another thread only using a proxy to tie back to a rendered object. I don't know anything about how PhysX ties into this though. My only experience is with an entirely proprietary simulation engine divested of the Unity core.

[magnemoe]

Just turned on FPS and it shows around 10 for an 200 part ship cruising out of Kerbin SOI on its way to Jool. Does not feel like 10 fps at all, but looks like they does some tricks as it feels smooth. 
As for launches its 3rd in an row. 1 the Tylo lander, second the manned mission, 3 is more methane and two Laythe probes and two probes trying to enter Jool for science. Likely to launch an 4th with just more hydrogen, Jool window is closing and one and a half year to it open again so has to throw stuff now. 

Now the burns are perfect, did an 17 minutes and 1.600 m/s burn to Duna who ended inside Duna SOI, that is stupid impressive, 300 m/s was with chemical engines rest was with two nuclear and a bucket of hydrogen tanks.

The Jool fleet used stronger first stage so core was mostly intact into orbit, now this is probably wrong and me thinking KSP 1. 
Now I kind of suspect they cheat with the burns? but you can mess them up like my Duna mission tumbling. 

[KincaidFrankMF]

I'm guessing that so far the devs have focussed on performance improvements to graphics/rendering the Kerbol system so the game is playable, albeit with relatively simple rockets. Making more complex rockets performative should be on the radar at some point, you'd hope... but not as urgent as all the game-breaking stuff they've been fixing thus far.

[Mike S]

Thus far, everything that I can determine points directly to the game engine itself and not the graphics rendering.  I've played games in the past where I had a huge number of polygons going on and it would impact frame rate performance...Homeworld 1 and 2 their remastered updates for example.  Early in the game, ships were simple and limited in numbers.  This by design, you had to learn how to walk before running.  Regardless, frame rates were good.  As I got deeper into the game and the ships became more complex and numerous, and LARGE...performance greatly dropped.  The CPU was doing its best to keep up with the math going on...the GPU however, really struggled to keep up.  It failed.  Dialing back the eye candy and resolution helped, but there was a limit.  And watching the hardware monitor keep tabs on the CPU load, what cores were being heavily used, GPU load also being measured in the same ways.  If you needed an upgrade, it was obvious in those benchmarks....a CPU/GPU in the load ranges of over 90% were good indicators that some upgrades were needed.  It was an easy thing to understand for most.  There were work arounds.  Disable the eye candy, dial back the resolution....slap more RAM in, go bigger RAM in the GPU and on it went.  My last rig (used as a "TV" now) sports 24GB DDR3 with an Athlon FX8350 and an AMD 770 6GB DDR4 GPU with SSD for boot drives.  It is old, but still can play many of my games with ease.  Some, like Homeworld remastered...not so much.  KSP 1 it does "ok"...not great, but workable.  Modded?  lol...noooooooooo...

Enter this rig.  Not high end, but way more than a match for pretty much every game EXCEPT KSP 2!  AMD Ryzen 5600 with 32GB DDR4 (3200) and a 6650 with 8GB DDR 5, with a 120MHz monitor to take advantage of some high frame rates.  Memory is running dual channel at rated clock.  Games like Homeworld are no problem...at all.  I've cranked all the eye candy up and get over 60FPS late game....Fallout 4 used to have issues with frame drops and regular and weird "pauses" if I cranked up the eye candy.  Not anymore.  Fallout 76 was the same.  Not anymore.  Starfield (crap game tbh), I was sporting 120FPS....same can be said of Star Wars Jedi series, Kingdom Come: Deliverance, GTA V and more...those games pose no challenge to this hardware.  At all.  Which is great for me.  And as I said, not a high end rig.  Horizon: Zero Dawn...I crank up all the eye candy that game has to offer and still maintain 120FPS without breaking a sweat.

This game?  KSP 2?  It matters not what graphics settings I have set. I could go lowest settings or highest settings and the results would be mostly identical.  When I first ran the most recent update in December, no mods and a clean install...frame rates were great.  I was looking at 120FPS in the load screen and saw modest drops as I began a new game.  Progression was fine, but frame rates steadily began to drop as I went through the different missions.  My ships gradually became more and more complex.  And with that, my frame rates dropped to dismal levels.

While watching this happen, second monitor had all the hardware stats going on, giving me real time info on what was going on.  Reality is this.  True frame rates were not being displayed.  At least, not in the sense of what my GPU was capable of showing me.  Pause the game and instantly the frame rates climb into the 50s for example...I can move around the ship and zoom in/out and all the other fun stuff with the mouse/KB and see no lag, no frame drops of any kind...related to vertices and the like...this is the same behaviour I would expect of other games like Homeworld.  But unlike Homeworld, the moment I unpause the game, I have an immediate drop to 5 FPS or less...on a ship with about 450 parts at launch.  20 minutes later, the boosters were dumped at about 35KM, knocking off about 20 parts and giving me a 2 FPS boost when those fell out of visual range.

In the time it took me to tap out the above, my ship finally made orbit at 100km...I am not a slow typer, I use all the fingers and thumbs, but it still took me a bit....lol  

But really.  The The CPU barely registers over 15% on any single core...the GPU even less on average.  KSP 1 had a similar problem, but that one had more to do with the part library itself being too large, rather than a very complex ship causing poor performance.  At least, in my experience.  KSP 2 however, behaves like a hungover mule.  There is lag going on, but it doesn't look obvious where the problem actually is.  As though the rendered information from the CPU takes a jaunt to the "Mun" and returns back to the GPU to render the first frame before sending the handshake, taking the same route back.  I honestly don't know what to make of it...all the other games I mentioned above?  I see heavy GPU/CPU/Memory activity...KSP 2?  Memory sure does get hogged up in a hurry, but never crests 20GB...it's like trying to move a bunch of files from one hard disk to another...a single 20 GB video will transfer from one SSD to another far faster than 20GB of 30kb text files ever will.  I wonder if that is what is at issue with the performance?

Would the game benefit from some kind of post "re-render" of the ship when going to the launch pad?  Instead of a capsule and parachutes being separate as in the vab, they are now one object on the launch pad...hidden vertices removed.  Not sure if that is even possible.  But something isn't working as expected.  It is taking a LOT of the joy of this game away, and that is a shame.

 

[Mike S]

On a lark, decided to fire up KCD while I wait for KSP to get my ship into orbit.  Over 72FPS in THAT game while KSP 2 renders at 3 FPS to orbit...lol

[chefsbrian]

18 hours ago, Mike S said:

I wonder if that is what is at issue with the performance?

I suspect its physics related. There may be oversimulation going on, and your extremely limited in your ability to run the calculations in parallel - So you end up with one thread on one core going pedal to the metal, and everything else chilling, because each part needs to walk through its physics operations, in order, and when they're all welded together they're all influencing and affecting each other,  plus occlusion calculations for atmospheric resistance and drag, all of which get more expensive the more objects that both need to be calculated, and correctly influence one another. Get it wrong, and you end up with Kraken drives and phantom forces.

As for why this affects rendered frames? It may be possible to decouple frame rendering from physics updates, but for a game like KSP its sort of pointless - you'd smoothly rotate and observe a ship that's still chugging at 3 updates per second, with all the associated control input latency still. There's also an overhead to pay just from the decoupling, and its still only a "may" - It could very well be that something in the physics calculations is being offloaded to the GPU where possible (And in fact, I think they're doing this with drag occlusion now that I put my brain to it) that could make it untenable as you need to sync the physics steps with the render steps at that point.

While there's always something that can be optimized a bit more, the only real way to see major gains on a real time physics simulation workload is to have higher single core speeds, less physics interactions, or simplified calculations. Replacing a complex drag and occlusion model with a simple "Occluded yes/no" and fixed "drag" value would vastly reduce the load, but would just as badly impact the accuracy of the simulation, the game would be entirely arcade physics just from that. Finding that balance point is difficult, and not really easy to work out on paper - you can theory craft a way to reduce a cycle, but the only real way to tell if it still behaves "close enough" is to implement and observe/simulate it running.

TL;DR Games running frames lockstep with physics, and physics scales negatively as part count increases, and there's not many options to improve it.

[Mike S]

On 2/19/2024 at 9:37 PM, chefsbrian said:

 

TL;DR Games running frames lockstep with physics, and physics scales negatively as part count increases, and there's not many options to improve it.

I would like to think that there would be a way to weld the parts as "one" when going to the launch pad...an engine and fuel tank with a decoupler are now a single object rather than three separate.  Probably way easier said than done.

That said, a lot of the parts I use are mainly for reaching orbit for the very heavy craft I am trying to push out and the most powerful engine doesn't have a nice way to couple 2 or more engines on without it looking stupid.  Limited functionality in the engine plates doesn't help, and the largest one available is too small for the largest tanks.  It's more an OCD thing really, so I end up using multiple lesser engines to match the output power, but they end up increasing the mass and negating any benefit to TWR.  And the complexity of the engines with gimbles doesn't help, the performance suffers with the additional animation and associated "physics" for every engine added.  This is where I am sure most of my issues lay. 

If I launch the payload portion of the ship without the launch vehicle, I do not suffer the severe performance penalties, and this despite a great deal of the 400 parts in this portion of the entire craft when I was using "cheat" to test some things as I developed the ship.   Even on the pad with engines off on the launcher, the performance is horrible.  At some point the devs will hopefully increase the tool box to include bi/tri/quad and penta mounts in the 5 meter space for the larger engines....I am hoping the mod community also addresses this and provide engine options for huge craft with multiple engines not unlike what SpaceX is doing with their heavy lifters. a bit like KSP 1, but hopefully not without the Kraken.   If I can simplify the launch vehicle, that would make a significant difference in performance.