Places to eliminate rigid body physics rather than optimze

[poopslayer78]

Performance seems to be a universal concern among the KSP2 community and there seems to be a consistent request for improvements.  Based on the ESA footage and scraps of other evidence, many speculate that the bottleneck is single threaded rigid body calculations.  This thread will work under the assumption that rigid body physics is currently a major FPS bottleneck, so my apologies if this is not actually true.

Also, this thread will not be concerned with optimizations to the physics engine, but instead suggest parts of the game where physics can be eliminated entirely, so the calculations are not necessary in the first place:

1. Connections between vertically stacked fuel tanks
   1. Either make the connections non-wobbly aka "welded".
   2. Or make fuel tanks procedural
2. Colony buildings - In my mind putting colony buildings under physics adds no fun and opens tons of potential for frustration.  For example, colonies spontaneously exploding when switching to them, or a launch pad tilting slightly.  Not to mention the performance overhead.  Consider thinking of a different mechanic to constrain colony building, such as construction resources or static limits within the base assembly editor for things like mass, height, height/width ratio, etc.
3. Delivery routes - If these are not in the immediate vicinity of a player, automated delivery vehicles should be non-physical and on rails so they don't spontaneously fail off screen.

I'd also like to mention that most players don't actually seem to like wobbly rockets in KSP1 based on 2 observations:

1. Cognitive: Players have explicitly stated on various KSP2 social media platforms that they aren't very nostalgic or heavily invested in wobbly rockets and a lack of pushback saying "keep rockets wobbly".
2. Behavioral: Most players eventually learn to auto strut or spam manual struts until their vehicle becomes rigid.  Reid Captain summed this up well by lamenting that "the game is actively playing against itself here" when talking about his gameplay loop of build rocket -> it's too wobbly -> spam struts -> bad performance.

Edited February 23, 2023 by poopslayer78
Minor grammar & clarity fixes

[intelliCom]

I suspect the problem may actually lie with fuel crossfeed, at least based on one case.

When Everyday Astronaut played it, he set up an onion stage of 8 boosters with aerospike engines, each booster having 4 fuel tanks. Once launching the rocket, the frame rate came to an absolute crawl, with the game running at half speed. The moment those boosters were jettisoned, the performance immediately improved.

The thing is, if physics is a source of performance issues, why would performance issues disappear on stage separation, even though the boosters are still there, still having their physics calculated?

EDIT:
Some of you may remember that fuel crossfeed was actually a performance issue for KSP1 as well. Stratzenblitz encountered it in his video; "Building a 1 Million Ton Rocket", where he had to optimise the rocket by giving each rocket engine only one fuel tank, minimising performance losses from crossfeed calculations. I suspect a worse version of this is present in KSP2 at the moment, requiring development time to hopefully resolve it.

Edited February 23, 2023 by intelliCom

[darthgently]

12 minutes ago, intelliCom said:

I suspect the problem may actually lie with fuel crossfeed, at least based on one case.

When Everyday Astronaut played it, he set up an onion stage of 8 boosters with aerospike engines, each booster having 4 fuel tanks. Once launching the rocket, the frame rate came to an absolute crawl, with the game running at half speed. The moment those boosters were jettisoned, the performance immediately improved.

The thing is, if physics is a source of performance issues, why would performance issues disappear on stage separation, even though the boosters are still there, still having their physics calculated?

Everyday Astro's results made me wonder if the devs may have borrowed some KSP1 code with regards multiple engines sharing multiple fuel sources causing the bulk of frame rate decrease on ascent. 

I wish I could remember the vid, but a content creator very rigorously tracked this down.  Definitely frame rate in KSP1 is inversely proportional to the square of number of engines and shared tanks or similar.  Geometric, exponential, can't remember for sure.  But sloooow

Edit: sorry, I replied without scrolling to see your entire post on my tiny phone.  Stratzenblitz it surely was indeed that spied the tangled web of fuel crossfeed

Edited February 23, 2023 by darthgently

[Profugo Barbatus]

6 minutes ago, intelliCom said:

The thing is, if physics is a source of performance issues, why would performance issues disappear on stage separation, even though the boosters are still there, still having their physics calculated?

Because the expensive part of physics calculations is resolving collisions, not existing/moving without collisions. Colliders are hella expensive, and parts wobbling into each other would basically stack a collision every physics frame.

That being said, fuel/resource drain is certainly a potential candidate. Collisions shouldn't be that expensive, and the new resource system for drains and faucets is new - wouldn't be surprising for it to recreate old bugs, if in novel new ways.

[intelliCom]

4 minutes ago, Profugo Barbatus said:

Colliders are hella expensive, and parts wobbling into each other would basically stack a collision every physics frame.

This assumes that the parts of a single, contiguous craft in KSP2 are now automatically self-colliding. They didn't self-collide in KSP1 without turning on "same vessel interaction" for the parts that needed to collide.

[Profugo Barbatus]

1 minute ago, intelliCom said:

This assumes that the parts of a single, contiguous craft in KSP2 are now automatically self-colliding. They didn't self-collide in KSP1 without turning on "same vessel interaction" for the parts that needed to collide.

I've seen stupider settings left on/off in release copies of games that caused no shortage of trouble. Callisto Protocol basically tanked its launch reputation by forgetting a single engine level setting to precompile shaders. Forgetting about a physics checkbox because "there's more important things, that's easy so I'll fix it later I won't forget" happens all the time. I'm even guilty of it in my dayjob.

[TackleMcClean]

I think if the development team wants good feedback, then the players deserve a good explanation of the current physics system - good and bad.

How was it built, what can we expect etc? Is it basically KSP1 physics? Is it written from scratch?

It's not good use of people's time to second guess everything. It's better to put all the cards on the table so both developer and community can focus on making the best possible game. I hope the current community worries to the bad performance wont hinder them from being honest and clear about this, IF the goal truly is to get good feedback and improve the game.

[VlonaldKerman]

5 hours ago, TackleMcClean said:

I think if the development team wants good feedback, then the players deserve a good explanation of the current physics system - good and bad.

I think this applies generally to all the systems in KSP 2 that are either implemented impartially/inefficiently, and the ones which are in-development and coming soon. The current relative lack of transparency leads to wild speculation and widespread skepticism within the KSP community, as is evident everywhere you go in this forum. Not to mention, for how truly early the early access build is, I think it's reasonable to expect a level of transparency that's VERY VERY elevated relative to other games, even other beta releases. ESPECIALLY given they are charging $50 for a promise.

[Ashandalar]

11 hours ago, darthgently said:

Everyday Astro's results made me wonder if the devs may have borrowed some KSP1 code with regards multiple engines sharing multiple fuel sources causing the bulk of frame rate decrease on ascent. 

I wish I could remember the vid, but a content creator very rigorously tracked this down.  Definitely frame rate in KSP1 is inversely proportional to the square of number of engines and shared tanks or similar.  Geometric, exponential, can't remember for sure.  But sloooow

Edit: sorry, I replied without scrolling to see your entire post on my tiny phone.  Stratzenblitz it surely was indeed that spied the tangled web of fuel crossfeed

My guess would be quadratic (square), since this is the scaling of the number of distinct pairs of elements as the number of elements increases: there are n(n-1)/2 distinct pairs for n elements.

[darthgently]

Programming challenge:

Do fuel crossfeed calculations using the GPU or via other unused cores.

If the fuel levels can be encoded as hidden bitmap pixel values..

Or if the entire crossfeed calc could be done on another core...

 

[Cailean_556]

I'd be okay with non-wobbly rockets - even more so with modular, orbitally constructed vessels. Like, if instead of using docking ports to dock parts together they used a "magnetic joint" - works the same way (i.e. you dock to it and it crossfeeds fuel, you just can't transfer Kerbals through them) however anything connected using these joints the game considers anything attached using them is solidly attached to the craft, moving as one part (not wobbling around fighting itself until the Kraken appears). And if the crossfeed is actually causing the FPS drops...I'm hoping that gets resolved sooner in KSP2s EA cycle than later - as EVERYONE is going to build rockets that require crossfeed - especially for lower stages.

[lordbunson]

On the reddit dev performance update thread  they mention that fuel cross feeding is one of the contributing factors to poor performance.  The development team talked so much about rebuilding from the ground up to overcome the limitations of KSP 1, now we find out that KSP 2 is plagued by one of the primary limitations of KSP 1 (but even worse than before)

As far as other discussion points go,  I would love for both procedural tanks and welded parts.  I some how convinced myself that procedural fuel tanks was one of the promised features and am dissapointed that it isn't in the game