Performance KSP2 is Calculating the Physics of all Parts of all Crafts Whether They are Rendered or Not, Reducing Performance of all Scenes at all Times.

[Anth12]

KSP2 Version: 0.1.0.0.20892
KSP2 Version: 0.1.1.0.21572
KSP1 Version: 1.12.5 + DLCS
Operating System: Windows 10
CPU+GPU+RAM: i9 9900K+3070ti+32GB
Mods Used: Lazy Orbits to cheat crafts into orbit and planets (removed for actual testing)

Expected Behaviour:
That when a craft isn't rendered the game treats 1 craft as one entity (no matter how many parts it has) and that the craft is on rails to improve overall performance.
Observed Behaviour:
That KSP2 is calculating the physics of all parts of all crafts whether they are rendered or not causing performance issues.

How Evidence Was Compiled:

I did the following for KSP1 and KSP2:

• Put 8 1000 part crafts in orbits around different planets/moons
• Put a 1 part craft on the surface of Vall
• I recorded the ms/frame (KSP2) or FPS (KSP1) for 8001 parts while having only the 1 part craft in scene on Vall.
• Went to the tracking station and deleted 1 1000 part craft reducing the part count total to 7001 and then tested on Vall again.
• Went to the tracking station and deleted 1 1000 part craft reducing the part count total to 6001 and then tested on Vall again.
• Went to the tracking station and deleted 1 1000 part craft reducing the part count total to 5001 and then tested on Vall again.
• Went to the tracking station and deleted 1 1000 part craft reducing the part count total to 4001 and then tested on Vall again.
• Went to the tracking station and deleted 1 1000 part craft reducing the part count total to 3001 and then tested on Vall again.
• Went to the tracking station and deleted 1 1000 part craft reducing the part count total to 2001 and then tested on Vall again.
• Went to the tracking station and deleted 1 1000 part craft reducing the part count total to 1001 and then tested on Vall again.
• Went to the tracking station and deleted 1 1000 part craft reducing the part count total to 1 and then tested on Vall again.
• I recorded all of the results and put them into a graph.

Video Evidence:
Note I have timestamped each performance test for faster navigation of the videos.
KSP1: https://youtu.be/v8Q8LkIPu_s?t=12
KSP2: https://youtu.be/W-syZ8Vdt7o

 

Results from Videos on a Graph (lower is better):

Note I converted the FPS of KSP1 to ms/frame. (Mortoc shout out for that)

Conclusion:
KSP1 only calculates 1 craft as 1 part when it isn't rendered and is out of physics range.
KSP2 calculates the physics of every part of every craft in a save causing performance issues the more total parts there are in a save file.

Additional Information:
Note how useful a Set Orbit/Set Position (from KSP1) option would be for these kinds of tests if it was added to KSP2?
Using mods for bug reports makes me feel uncomfortable but currently I can't do this type of bug report without Lazy Orbits.

Files:
KSP2 8001 part save
KSP1 8001 part save
KSP2 1000 part craft (Appears that 0.1.1.0 thinks this is now too big to launch from the VAB)
https://www.dropbox.com/sh/g5a5214kmgo04bl/AADXpu_9168fl3XavdlIASOja?dl=0

[JoeSchmuckatelli]

Wow dude - that is some work! 

[Anth12]

28 minutes ago, JoeSchmuckatelli said:

Wow dude - that is some work! 

Thanks. What you see there looks simple and straight forward I hope? Took me days getting it to that point.

[MehJeb]

Yeah, you definitely took some time doing this ) I think, for experiment to be a success you'd need half of data points, say 8001, 4001, 1  - the graph would look the same...

Your findings are very impressive and this topic\bugrep should be marked as VERY IMPORTANT - ofc, the KSP1 approach is correct - once you don't have the craft loaded in scene - do nothing for it (thou KSP1 actually goes one step further and does calculate collision of objects on sub-orbital trajectories). This _stupidity_ is, ofc, a runaway process - and processing individual parts of craft that are not in scene is ridiculous!

[JoeSchmuckatelli]

@Nerdy_Mike and @Dakota-of any community feedback that gets elevated... This OP should be at the top. 

[The Aziz]

The sun is not being rendered until below 1500km and yet it affects every craft.

The physics LOD the team mentioned a couple of times is probably not quite refined yet, being 0.1.1. But have you noticed how there's no sudden freeze when a craft gets within psychics range, like it was in KSP1?

[TomKerbal]

@Anth12 How does the performance curve look like if you always switch to one of your 1000 parts vessels instead of your 1 part vessel ?

 

Edited March 20 by TomKerbal

[WingC3]

It's possible that this calculation is intentional, though probably not the performance drop. If it is true that interstellar craft will be burning for years at a time, then the only way for the player to do anything else but fly that craft during that time period is for the game to continue calculating updates for that craft even when it's out of focus. But clearly, if there's any hope of decent performance for this, especially with colonies and trade runs happening on top of this, they are going to have to optimise the HECK out of this.

I cannot see how we will see any of those features on a time scale shorter than years at the moment. That being said, if they can keep churning out 300+ fixes per patch, I could be wrong!

[Anth12]

1 hour ago, TomKerbal said:

@Anth12 How does the performance curve look like if you always switch to one of your 1000 parts vessels instead of your 1 part vessel ?

Didn't test for that sorry.

[Anth12]

@Dakota

Did retesting for this without the Lazy Orbits mod (teleport cheat) after what Nate said for the AMA:
Tested with 10 250 part crafts manually launched into Kerbin orbit and left a pod+docking port on the Mun after launching and landing that normally as well.

Note the graph shows the same trend without the Lazy Orbits mod teleporting crafts
Results are slightly elevated probably due to the in scene craft being a pod and a capsule instead of a girder segment.

Graph Results:

Save File for retesting:
https://www.dropbox.com/s/h61qxnik0395zpj/Focus%202%20Part%20Craft%202502%20Save.zip?dl=0

[DibzNr]

I believe this may be an intentional consession made to ease the implementation of multiplayer

[JoeSchmuckatelli]

The more we progress through this - the more I wonder if the requirements for multiplayer isn't screwing up everything for everyone. 

(You read from people who know what they're talking about how MP has to be baked in from the beginning, hear from Nate how every system and part has to be proofed by the MP team before proceeding and compare that to the state of the game... And it's a likely explanation.  Not perhaps to the instant discussion, but as the background for a lot of the seemingly questionable choices and limitations of KSP2 when we expected* so much more.) 

 

*were led to expect a much deeper, better experience than we got. 

Edited April 19 by JoeSchmuckatelli

[Anth12]

11 minutes ago, DibzNr said:

I believe this may be an intentional consession made to ease the implementation of multiplayer

I dont think multiplayer needs to have every part physics calculated.

I did some testing. The parts aren't even rendered and aren't under acceleration. Crafts only need to be calculated as 1 part when they aren't rendered and aren't close to physics range.

4 minutes ago, JoeSchmuckatelli said:

The more we progress through this - the more I wonder if the requirements for multiplayer isn't screwing up everything for everyone

It's probably just that they haven't added the next piece of code that reduces the part count calculations down to 1 part for 1 craft when out of render range.

[Lyneira]

Good work on finding this out! No doubt optimizations for this are planned for the future, as this will be essential to run a larger multiplayer savegame with multiple craft from multiple players in flight. I could see this being a case of deferring premature optimization until they have their internal multiplayer prototype working better. Once that's the case, there should still be lots of room to improve on this.

[Anth12]

20 minutes ago, Lyneira said:

Good work on finding this out! No doubt optimizations for this are planned for the future, as this will be essential to run a larger multiplayer savegame with multiple craft from multiple players in flight. I could see this being a case of deferring premature optimization until they have their internal multiplayer prototype working better. Once that's the case, there should still be lots of room to improve on this.

Maybe. I am not convinced its a multiplayer issue. More of a 1 step at a time development thing. Think of this issue as an uncompressed file compared to a zip file maybe.

 

[JoeSchmuckatelli]

9 hours ago, Anth12 said:

Maybe. I am not convinced its a multiplayer issue. More of a 1 step at a time development thing. Think of this issue as an uncompressed file compared to a zip file maybe.

 

My fault for injection of a thought unrelated to the instant discussion.  It was meant as a general observation