I'm still wondering how they're gonna solve atrocious performance with ginormous crafts within physics range (+500 parts)

[MARL_Mk1]

I can't imagine the scenario where you arrive at your 400 part orbital dock with your 200 part interplanetary tug, then switch to your 120 part lander and make a pinpoint lander on your 500 part surface colony, with all of it being physics simulated and rocking more than 30fps.

In KSP1 I always felt like I had to ultra optimize on part count because performance degraded badly rather quick.

[The Aziz]

With gigantic parts coming to play, I don't think such large part counts are necessary.

[cocoscacao]

@The Aziz keep in mind that this time around, all vessels count as active ones. I'm curious too. 

[The Aziz]

So you would have problems even when the four in question would be on the opposite sides of the solar system. Entering the physics bubble wouldn't make a difference if what you're saying it's true.

[Buzz313th]

1 hour ago, The Aziz said:

With gigantic parts coming to play, I don't think such large part counts are necessary.

Won't gigantic parts dumb down the engineering depth and challenge and dilute the potential ship diversity that we all loved with KSP1?

Are gigantic parts the solution to a performance limit on vessel part count?

[Royalswissarmyknife]

34 minutes ago, Buzz313th said:

Won't gigantic parts dumb down the engineering depth and challenge and dilute the potential ship diversity that we all loved with KSP1?

It depends what the giant parts are. If its something like a gravity rings, Colony parts and science parts before then I would say no.

As long as they dont remove any parts from Ksp-1 and replace them with larger parts it should be fine.

I just hope they dont use big parts as an excuse to ignore the performance issues.

Spoiler

One of my main concern is if they never add bare engine variant's as a parts switch. Because of this single missing feature is one of the largest reasons I dont use Ksp-2 as a sandbox

Another major concern is if the Engine Panels from Ksp-1 will come and if they are Recolorable. 

 

Edited December 9, 2023 by Royalswissarmyknife

[MARL_Mk1]

2 hours ago, The Aziz said:

With gigantic parts coming to play, I don't think such large part counts are necessary.

So you are saying that you'd embrace the inherited problem of big part count = massive performance loss either way as long as you got big parts to counter the issue? What would be the point of KSP2's existence then if the main problems the first game had will still be there either way with computers multiple orders of magnitude more powerful required to run it?

Those are incompatible statements. If they really plan on releasing a good KSP2 experience on console we should expect no less (and so do they if they plan on making any money out of said platforms). I'm also aware that the game has a literal impossible way to determine system specs the same way traditional games do it based on the fact that you can build things that would choke a NASA supercomputer, but think for a second about the scenarios I wrote about in the first post.

When colonies become a thing, people will want to build rather big things without their game feeling like KSP2's February release build. I already want to build big things and I feel like I'm being held back, since a 200 part craft in KSP1 still delivers better performance than on KSP2. And I expect this to change drastically if this game wants any chance of being half of successful as the first game was.

I'm just curious about their plans on that regard because Nate has mentioned that they aim for roadmap updates not taking as long as For Science has from release to current day (~10 months). We might be looking at a Colonies update coming between June and September 24' being generous, so I'd hope for them to share their plans on further performance optmizations beyond what they are working at with the terrain system rebuild and whatnot.
 

Edited December 9, 2023 by MARL_Mk1

[The Aziz]

1 hour ago, Buzz313th said:

Won't gigantic parts dumb down the engineering depth and challenge and dilute the potential ship diversity that we all loved with KSP1?

Uh, no, why? Build your ship from 7500 short 1.25m tanks if you like, but if I need a long truss to keep things separated from each other, I'm gonna use it because it's convenient. The choice is still there. If you want a small ship, build it from small parts, if you want it big - you know where to look instead of stacking more small parts.

50 minutes ago, Royalswissarmyknife said:

Another major concern is if the Engine Panels from Ksp-1 will come and if they are Recolorable. 

You mean engine plates? They're already there last time I checked.

48 minutes ago, MARL_Mk1 said:

So you are saying that you'd embrace the inherited problem of big part count = massive performance loss either way as long as you got big parts to counter the issue?

See above. The existence of big parts means I don't have to use three times as many small parts to get the same effect (mostly resource/crew capacity). The problem solves itself without me even thinking about it.

[Buzz313th]

Just now, The Aziz said:

Uh, no, why? Build your ship from 7500 short 1.25m tanks if you like, but if I need a long truss to keep things separated from each other, I'm gonna use it because it's convenient. The choice is still there. If you want a small ship, build it from small parts, if you want it big - you know where to look instead of stacking more small parts.

You mean engine plates? They're already there last time I checked.

See above. The existence of big parts means I don't have to use three times as many small parts to get the same effect (mostly resource/crew capacity). The problem solves itself without me even thinking about it.

I was thinking "Combo Parts" instead of larger parts of a particular type and function.  Like a hab section part that has RCS, resource and other parts baked in to increase the functionality but not "Part Count".   Hopefully it's only larger versions of particular parts as you say..

[Bej Kerman]

2 minutes ago, Buzz313th said:

I was thinking "Combo Parts" instead of larger parts of a particular type and function.  Like a hab section part that has RCS, resource and other parts baked in to increase the functionality but not "Part Count".   Hopefully it's only larger versions of particular parts as you say..

A more sustainable solution would probably involve LODs, so parts act that way at a distance without being permanently baked and further padding the parts list with various combinations in the VAB.

[Royalswissarmyknife]

1 hour ago, The Aziz said:

You mean engine plates? They're already there last time I checked.

I meant radiator panels. Engine was a typo.

 

[PDCWolf]

8 hours ago, MARL_Mk1 said:

I can't imagine the scenario where you arrive at your 400 part orbital dock with your 200 part interplanetary tug, then switch to your 120 part lander and make a pinpoint lander on your 500 part surface colony, with all of it being physics simulated and rocking more than 30fps.

In KSP1 I always felt like I had to ultra optimize on part count because performance degraded badly rather quick.

This is one of the points where I feel doomerism is probably the most justified. Seeing a 1 part full gravity ring, and a 20 part "huge interstellar mothership" is such a turnoff.

KSP2 is saving more data than KSP1 for an individual part, it needs to for off-focus thrust, as it can't just dump unloaded vessels into a 1part protovessel like KSP1 did. If you add that to their heavy reluctance to claim maximum part numbers, the trend of dumbing down constructions (and now science parts) to 1 part solutions... yeah it doesn't look good, and that's seemingly by design in a way to reduce both save bloat and to keep the game performant as you build and launch stuff. As of now it looks like KSP2 is gonna have a much tighter part count/vessel per-save limit versus the prequel.

So yeah, my answer would be "they're not gonna solve it", or "maybe they can optimize it a bit but the overall limitations are already mostly set".

6 hours ago, The Aziz said:

So you would have problems even when the four in question would be on the opposite sides of the solar system. Entering the physics bubble wouldn't make a difference if what you're saying it's true.

Entering the bubble would still load the models/textures and physics, so approaching a part-dense craft will still have an impact as it enters the physics bubble.

6 hours ago, Buzz313th said:

Won't gigantic parts dumb down the engineering depth and challenge and dilute the potential ship diversity that we all loved with KSP1?

Are gigantic parts the solution to a performance limit on vessel part count?

Yes to all, unless you actively refuse to use them and build things manually. Less parts = less possible combinations, that's basic math. If they only do one gravity ring, then every player's gravity rings are gonna look the same.

[mcwaffles2003]

Wasn't an issue with KSP that it wasn't multithreaded and KSP is heading in a multithreaded direction? I understand there are cache sharing issues with multithreading a single craft but couldn't multiple threads be dedicated to multiple craft? I assume this might create a lag spike when craft come into contact as the 2 threads will have to merge or something so that part positions can sit on the same cache but wouldn't this mean a great performance improvement overall everywhere else in environments with multiple craft which seems to be a goal of KSP2?

 

Also, I never suspected that we would ever have have a performance improvement in regards to part count affecting performance on the RBD side (though a lot of performance issues for high part count craft in KSP 1 stemmed from the fuel flow system as shown by stratenblitz in one of his videos) though there was a lot of speculation RBD could be streamlined for better performance by making full collections of parts fused, artificially lowering part count by making those collections act as single rigid parts collectively. I assume adding a system like this could still happen down the line when the game gets to a state where many players are finally playing it and getting to those kinds of part numbers in their crafts despite the slight diminishment of realism as a result. It would certainly be a trade off though in the realm of realism vs game, but it's one I would personally support if performance improvement was significant.

[Periple]

It is going to be tricky! Maybe some kind of physics LoD system where parts are auto-welded to cap the physics part count at some reasonable number? From the player’s PoV there isn’t much difference between a craft being simulated as 100 parts instead of 1000 parts.

[MARL_Mk1]

18 hours ago, The Aziz said:

See above. The existence of big parts means I don't have to use three times as many small parts to get the same effect (mostly resource/crew capacity). The problem solves itself without me even thinking about it.

I don't mean that, and I think you are steering the convo in a different direction with the big parts thing. I'm merely talking about the inherent need of people to build very large crafts and colonies. Colonies in particular will get really big. We've seen modular road parts and such, so we can expect people to build big, surface outposts in the hundreds of parts count. Same goes for big orbital docks and space stations. Intercept has also glanced over the fact that high part vehicles will need to be performant by the time Interstellar is around.

The question I think fits this better would be: in 3 years time, can I expect better performance from a 500 part build in KSP2 than from a 500 part build in KSP1 with a High End machine?

If the answer were no, then having paid for KSP2 (Early Access or not), will have not been worth it, and console versions of KSP2 would suffer the same fate as KSP1's console edition, where they were extremely limited on the part count and performance side.

People want that 'KSP1 and then some more'  promise to become real, just without the inherited core problems the original game had.
If the same issues persist or get worse, there is literally no point for KSP2 to exist.

Big parts solve the issue in KSP2 the same way big parts would've solved it in KSP1: Not solving it.

Edited December 10, 2023 by MARL_Mk1

[kdaviper]

18 minutes ago, MARL_Mk1 said:

I don't mean that, and I think you are steering the convo in a different direction with the big parts thing. I'm merely talking about the inherent need of people to build very large crafts and colonies. Colonies in particular will get really big. We've seen modular road parts and such, so we can expect people to build big, surface outposts in the hundreds of parts count. Same goes for big orbital docks and space stations. Intercept has also glanced over the fact that high part vehicles will need to be performant by the time Interstellar is around.

The question I think fits this better would be: in 3 years time, can I expect better performance from a 500 part build in KSP2 than from a 500 part build in KSP1 with a High End machine?

If the answer were no, then having paid for KSP2 (Early Access or not), will have not been worth it, and console versions of KSP2 would suffer the same fate as KSP1's console edition, where they were extremely limited on the part count and performance side.

People want that 'KSP1 and then some more'  promise to become real, just without the inherited core problems the original game had.
If the same issues persist or get worse, there is literally no point for KSP2 to exist.

Big parts solve the issue in KSP2 the same way big parts would've solved it in KSP1: Not solving it.

Will colonies need their parts to be physically simulated in the same way space craft are?

[Kerbart]

Assuming a “colony” in space is a special beast — construction yard, launch docks, life support and the whole nine yards — I see no issue of it being a single part just like the launch tower or the VAB. Its a city in space, not a craft. 

I’d rather have it like that than slugging along at 5 fps.

[PDCWolf]

17 minutes ago, Kerbart said:

Assuming a “colony” in space is a special beast — construction yard, launch docks, life support and the whole nine yards — I see no issue of it being a single part just like the launch tower or the VAB. Its a city in space, not a craft. 

I’d rather have it like that than slugging along at 5 fps.

Colonies on the ground would probably have no physics, however they're still modular structures, which gives way to the possibility of having to simulate different resource producers, holders and requesters, all off-focus, which is already part of the problem. Of course, they could always abstract resources to single magical pools.

On the other hand, I doubt they'd go the same route for orbital shipyards, since those are also modular structures, and in fact sounded more like specially built craft (as in, a set of parts) than space colonies. Further on, if you want them physic/module less, you'd have to communicate to players that those shipyards once installed are magically no longer manipulable with engines or RCS, and damage would have to be global rather than per-part.

[MARL_Mk1]

3 hours ago, kdaviper said:

Will colonies need their parts to be physically simulated in the same way space craft are?

It has been stated in the past that they will be physically simulated. But lets assume for a second they aren't. Every other craft mentioned suffers the same issue either way.

[KUAR]

On 12/10/2023 at 7:43 AM, Periple said:

It is going to be tricky! Maybe some kind of physics LoD system where parts are auto-welded to cap the physics part count at some reasonable number? From the player’s PoV there isn’t much difference between a craft being simulated as 100 parts instead of 1000 parts.

This is honestly the only way I see it working and I (perhaps naively) think that it should work. Perhaps it's an extension of sub-assemblies: you can define an assembly which is a rigid body, with a single resource storage/generation/specification characteristic, etc. etc. 

There would of course have to be limitations - decouplers/docking ports couldn't be in the middle of your assembly for instance, and perhaps it's progression-locked (rigid sub-assemblies up to X tonnes/Y parts, upgradeable like the VAB size/part count limits). It could also be limited to a certain percentage of your overall craft's mass or part count.

I can see that it would be complicated to implement with e.g. aero model, parts manager UI, etc. etc. but I see it as being the best option. A small number of large monolithic parts doesn't interest me as it'll kill variety. If they're going down that route then serious investment in part development would be required.

[Periple]

2 hours ago, KUAR said:

This is honestly the only way I see it working and I (perhaps naively) think that it should work. Perhaps it's an extension of sub-assemblies: you can define an assembly which is a rigid body, with a single resource storage/generation/specification characteristic, etc. etc. 

It would be some work but I don't think it would be HARD hard. I would assign affinities between different parts, iterate through the tree to weld each part to the highest-affinity neighbor, and recurse until I hit the target number of physics parts. So for example two parts with the same diameter attached through a node would have a high affinity, two parts with different diameters attached through a node would have medium affinity, a part attached to another part via a surface attachment would have low affinity, and certain parts like docking ports and decouplers would have zero affinity so they're never welded. 

Then you'd need to decide whether to recompute the welds when docking in space and handle any issues that might cause, it sounds like the kind of thing that could summon the kraken if not handled carefully. 

There would have to be a halt condition if an iteration resulted in no new welds -- that would mean that some lunatic built a craft entirely out of decouplers and docking ports. That would still result in an abnormal part count but I think it would be quite unlikely except as an experiment so anyone so inclined would just have to take the performance hit.

[KUAR]

That's good and I agree...but figuring out the new drag cube maths will be interesting!

[Periple]

1 hour ago, KUAR said:

That's good and I agree...but figuring out the new drag cube maths will be interesting!

I'm sure that could all be precomputed but I don't know if it's even necessary. I'm pretty sure the bottleneck is with the rigid-body physics.