Performance is still not good with ships that have many parts

[KincaidFrankMF]

8 hours ago, Mike S said:

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.

Have you tried the old-school KSP1 approach? I.e., radially attach some big nose cones to your fuel tank, attach the mammoths to those, then offset the nose cones till they fit snuggly to the tank and look good.

[magnemoe]

On 2/20/2024 at 5:37 AM, chefsbrian said:

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.

We have the issue with items especially docking ports and probe cores overheating inside fairings if they are the front item who docking ports often is. 
So lots is going on on launch, aerodynamic, heating and of you use side boosters its additional forces in play. 
On top of this takeoff is also graphic intensive. 

It had been nice to be able to seal an fairing or cargo bay. Sealed it get the loaded weight and center of mass but is one item until opened. Obviously anything inside would not be usable until opened, this would be nice if you brings lots of probes or rovers. 
Having said this once in deep space I have no issues even during burns with ships with +200 parts. 

[KSRe-dev]

This needs more data to narrow down, the KSC seems the worst performing area of any that I've seen, and it may be specific to whatever is going on in that area. You would have to test those two vessels in space, and in other areas of Kerbin as well.

From some tests I know that parts are being fully simulated in the KSC even when they aren't active (PartModule is always running), unlike vessels which are e.g. in Mun orbit and inactive. This may not impact this test since its already the active vessel, but it could be a compound effect, or something else is going on around KSC.

 

[sid.tbms]

I did a brief test of my own and found it to be more of a logarithmic curve down, where it started at 60fps and quickly fell below 30, then leveled off in the teens a bit. 
It looks like 300 parts would likely be my design limit for any one vessel and hope that I'll not need three in the same area!

Here's my data, on a fresh creative save, without changing any settings or turning off one of the few mods I have. I used random blueprints I found with varied part counts for the test.
Take from that what you will:

Parts	Altitude	FPS
4	0	56
50	0	51
90	0	38
157	0	26
287	0	20
381	0	12
558	0	13
841	0	2
4	100	60
50	100	53
90	100	48
157	100	26
287	100	16
381	100	15
558	100	11
841	100	5
4	1000	60
50	1000	53
90	1000	48
157	1000	26
287	1000	16
381	1000	15
558	1000	12
841	1000	5

[Mike S]

On 2/23/2024 at 5:01 AM, KincaidFrankMF said:

Have you tried the old-school KSP1 approach? I.e., radially attach some big nose cones to your fuel tank, attach the mammoths to those, then offset the nose cones till they fit snuggly to the tank and look good.

 

Sorry for the late reply.

Yeah, I've done this.  The trouble however, is the complexity is itself the achilles here.  One engine plate and 8 engines radially around a center engine.  Versus several more tanks and cones to pretty it up and aerodynamic stuff.  The performance hit is insane.  I have this one craft that rivals Starship...12.5 meters wide, it sports an S4 tank with eight S3 tanks and cones radially and offset accordingly, with an additional bunch of FL-T800s and engines to fit a 33 engine count...TWR is sort of OK...all that extra tank mass isn't helping and also contributes to the problem.  More parts, severe performance hit.

https://imgur.com/a/3m9p5DQ

 

Edited March 16, 2024 by Mike S
too many thumbs.

[Mike S]

I am not sure if it is even possible to do what I have in mind...but in the real world, if we did radially mounted engines onto smaller tanks, only the outside shell of the tanks themselves would be there...the rest of the tank that was there, cut away to be a part of the larger center tank.  Reduction of the total mass an obvious result.  The game does not take this into account and regardless of how it is mounted, total mass of all the tanks are still counted, including volume of liquid inside.  TWR results no longer true to real world results.

Every object in the game suffers from this single problem.  It would be awesome if there was a plan or method to "re-render the ship" when we send to the launch pad...everything that is attached to one side of a coupler is a single entity, instead of several individual parts.  A fuel tank that is comprised of 3 parts, plus nose cone and engine...now all 1 part instead.  Attach that radially around another tank and offet...when re-rendered, all the internal bits are removed to simplify the model and presumably reduce the mass of what wouln't be there in a real world example.  Fewer things to process and keep tack of.  GTA V has a building feature to it that was simple, but used this concept of removing vertices and such to simplify the object when rendered in game.  Though to be honest, that game's toybox was pretty limited in what you had to work with.  Despite, performance didn't take a hit with a more complex looking ride.  Which is kind of the idea there.  Could they do this with KSP 2?  

[KerikBalm]

9 hours ago, beredisq said:

would depend on the game’s development roadmap and the priorities set by the developers.

[...]

it’s possible that either the developers or the modding community could explore ways to incorporate more realistic mass calculations into the game.

Ummm, have you not heard?

They are closing development of KSP2, in less than 60 days, the dev team will all be out of a job, and development of KSP2 will be over - only vague "support"

[Bej Kerman]

7 minutes ago, KerikBalm said:

Ummm, have you not heard?

They are closing development of KSP2, in less than 60 days, the dev team will all be out of a job, and development of KSP2 will be over - only vague "support"

TIL Nate is working directly at PD so he's safe, at least from what I've heard.

[KerikBalm]

49 minutes ago, Bej Kerman said:

TIL Nate is working directly at PD so he's safe, at least from what I've heard.

Maybe, maybe not, we'll see when the 60 days are up