I'm worried about the possible system requirements of KSP2

[K^2]

2 hours ago, GoldForest said:

A good air cooler and an aio have pretty much the same performance, so you don't really need an AIO. And Noctuas are very good air cooler.

A low budget AIO can be cheaper than D15, by a good margin sometimes, without sacrificing performance, and because of the thermal mass, it's not going to have to spin up the fans/pump if there is a short spike of load, which happens quite often in a lot of usage cases, which means that AIO can be quieter than a comparable air blower.

How much of a difference that makes for you particular case is up to you, and specifics will matter from build to build, but if you're going to drop $100 on cooling and don't at least consider liquid cooling instead, I have questions.

In contrast, unless you do have a high end CPU and/or are overclocking, maybe go with a much cheaper air blower instead. Something in $20-$40 range will do for most people in most cases, so long as they have an otherwise good air flow into the chassis. A $100 air blower is kind of a niche choice.

[GoldForest]

1 hour ago, K^2 said:

A low budget AIO can be cheaper than D15, by a good margin sometimes, without sacrificing performance, and because of the thermal mass, it's not going to have to spin up the fans/pump if there is a short spike of load, which happens quite often in a lot of usage cases, which means that AIO can be quieter than a comparable air blower.

How much of a difference that makes for you particular case is up to you, and specifics will matter from build to build, but if you're going to drop $100 on cooling and don't at least consider liquid cooling instead, I have questions.

In contrast, unless you do have a high end CPU and/or are overclocking, maybe go with a much cheaper air blower instead. Something in $20-$40 range will do for most people in most cases, so long as they have an otherwise good air flow into the chassis. A $100 air blower is kind of a niche choice.

I will admit, Noctuas are a little pricey, but they are worth it. If you want a cheap air cooler, the Cooler Master Hyper 212 Evo is a good option and performs rather well from what I've heard. 

AIOs come with the problem of a possible leak though. Even from the reputable brands like Corsair, and that's what worries people, I think. Yes, the chance of a leak is slim, but it's not zero. 

[K^2]

3 hours ago, GoldForest said:

AIOs come with the problem of a possible leak though. Even from the reputable brands like Corsair, and that's what worries people, I think. Yes, the chance of a leak is slim, but it's not zero.

That doesn't happen in practice with any sort of noteworthy frequency with modern AIOs. Not the sort of a leak where you'd have to worry about your system, at any rate. Small leaks causing loss of fluid over time do happen, which is one of the failure modes that can happen, typically after years of service. The other, as @Laikanautpoints out, is pump failure. But they'll still typically serve you for years without issues with proper installation and under moderate pump speeds.

So the risk isn't really there, and once you get into the price point of AIOs, they usually outperform air coolers dollar-for-dollar. You can also better manage the heat flow. One of the common problems of air blowers is that its' hard not to make your CPU be eating at least some of the GPU heat. But there are a lot of variables there.

3 hours ago, GoldForest said:

I will admit, Noctuas are a little pricey, but they are worth it.

For the specific niche where they make sense, sure. But it is a niche. So is the AIO, of course. All of this exists in this narrow sliver of space where a cheap cooler doesn't cut it anymore, but you're not at a point where you need to drive a custom loop through the monoblock to manage your thermals on the power delivery.

The main point here is not that you shouldn't be spending money on a good cooler. Rather, if a $40 cooler isn't doing the job, and you're eying a $100 cooler, you really should be considering your options. With most configurations and given how most cases on the market are organized, AIO will probably give you the same or better performance for $60-$80.

[SciMan]

I mean I've got a custom loop for my system, but that's because I wanted to put BOTH the CPU and GPU on the water cooling at the same time. Plus I don't trust the tiny little pump they put on the CPU block that AIO's have to not fail within a year or two.

Don't get me wrong, I love the idea of AIO's being an easily approachable solution to water cooling, I just don't trust the particular implementation of all the AIO's on the market (the pump being so tiny and... "value optimized" specifically).

They have a use case, just it doesn't cover MY use case since if I was going to use an AIO to cover both my CPU and GPU, well, I'd need 2 AIO's and at that point it becomes easier (if not always cheaper) to just use a custom loop in the first place right from the start.

Plus there's the serviceability part of the custom loop, if any single part has a problem, I don't have to replace the WHOLE LOOP, I can just replace the FEW parts that actually have issues, which means that a custom loop is more expensive to INITIALLY set up, but it's cheaper to keep going over time and from computer build to computer build (since you can easily transfer the parts between systems).

[K^2]

A custom loop is also fun to build. There's nothing wrong with making your computer be a little extra, even when you might not be pushing it to the kind of limits where it's absolutely necessary.

[whatsEJstandfor]

On 12/16/2022 at 3:09 AM, Laikanaut said:

I think generally AIOs outperform air coolers due to the vastly increased heat transfer through liquid compared to air, and if computing power continues to increase, liquid will likely become more common than air cooling due to this.

You'd think so, but GN did some tests a few years ago and found that, in general, in the best case, a good AIO vs a good air cooler results in only a few degrees cooler and, in the worst case, they're pretty much equal. There are other nuances but it's certainly convinced me to go back to a quality Noctua cooler the next time I build a PC, instead of the (very good) Corsair AIO I used this time around. For me, the small cooling benefit for the CPU is outweighed by an air cooler being able to also move more air for the other components, and the (admittedly very small) chance of an AIO failure.
 

 

[miklkit]

Airhead here who does not think water and electricity mix well. 

The problem with air cooling is the cases used these days.  They are optimized for silence, and what is the cheapest way to keep them quiet?  Restrict the air flow.  AIOs place the radiators and their heat in the exhaust so the case stays cool inside.  The heat from air coolers is trapped in the case and it turns into an oven.  Get an open case that enables good air flow and air coolers do much better.  In fact if the exhaust fan is removed and then the back of the case is cut out so the air cooler fans (which are by far the most powerful fans in the case) become the exhaust fans, then air cooling will surprise many.

Back in the AMD FX days I ran 5ghz CPUs at 1.5-1.55V 24/7 for years.  I bought a Silverstone HE01 cooler in 2013 and it went with one when I sold it in 2017.  Still worked fine.  In 2014 I bought a Thermalight Silver Arrow.  Still using it today on the rig I'm using now.  The worst "problem" is that a paper sticker fell off one of the fans.  This current system only runs at 1.35V and never gets over 60C. 

OTOH I had an AIO start leaking within weeks of installing it and it ran hotter than the air coolers anyway.

[SciMan]

Building on what @K^2 said, not only is a custom loop fun to build, but these days with the extremely high power dissipation of some brands of modern components (something like 250w for CPU and 600 w for GPU maximum thermal design power, respectively), a custom loop is practically the only way to get enough radiator area to keep temperatures down low enough so that the chips don't start their "oh I'm getting too hot I better start down-clocking" strategy that they use to get these high potential speeds while also being backwards compatible with older sockets and coolers (especially in the CPU market).

Basically, if I paid for a top of the line CPU or GPU, I don't want any chance of it thermal throttling. And that means I choose a case that has great airflow, I choose to go with a custom water cooling loop to keep the heat under control, and to keep the noise down I pick high quality Noctua fans and intelligently set my fan curves and water pump speed profile so that they're not constantly changing speed.

Yes, all of that costs time and money. But right now I'm sitting on a nice stable, quiet, and cool machine, my i7-9700k and RTX 3070 Ti have never gotten above 70C under sustained heavy load (3DMark Time Spy extreme stress test, run 5 times in a row with each run consisting of 20 runs of the benchmark proper, all at 4k resolution to take most advantage of the GPU).

Yes, I realize I'm CPU bottlenecked, and I'm planning on an upgrade to fix that. But that's gonna be expensive, cause I'm aiming for an i9-13900kf CPU, a high-spec motherboard to go with it, and fast DDR5 ram to tie it all together.

I'm awaiting further news about AIB partner's takes on the AMD 7900 XTX GPU to see if that's a worthy upgrade from my 3070 Ti as well, even tho I haven't even had this card all that long.

[K^2]

36 minutes ago, SciMan said:

But that's gonna be expensive, cause I'm aiming for an i9-13900kf CPU, a high-spec motherboard to go with it, and fast DDR5 ram to tie it all together.

I'm sure you're aware, but in case someone needs to hear this, when going for a high end CPU like that with plans to utilize it to the full, make sure you pay very close attention to the motherboard specs and cooling. Either find a water block that is designed to cover both your CPU and the power distribution on that specific mobo or get separate blocks for your power MOSFET banks. Among the worst experiences in custom PC building is giving a Pikachu stare to your 50°C CPU that's thermal throttling, because your stock MOSFET heat sink is hot enough to boil water.

Also, I'm really curious what sort of performance you'll get with that OC (I presume?) 13900KF with KSP2. So keep us posted once you have that upgraded and set up.

[TheOrios]

ksp 1 has existed for a while so internally it probably still has a lot of bottlenecks, like how it only ever uses 1 core.

ksp 2 is being buildt from the ground up, so most likely it will run much smoother compared to ksp 1, even on less powerful pcs

[GoldForest]

8 minutes ago, TheOrios said:

ksp 1 has existed for a while so internally it probably still has a lot of bottlenecks, like how it only ever uses 1 core.

ksp 2 is being buildt from the ground up, so most likely it will run much smoother compared to ksp 1, even on less powerful pcs

KSP uses multiple cores. It just uses 1 core for physics because of how Unity works and because calculating physics on more than one core could lead to problems. 

[TheOrios]

12 minutes ago, GoldForest said:

KSP uses multiple cores. It just uses 1 core for physics because of how Unity works and because calculating physics on more than one core could lead to problems. 

didnt know that, thx

[tstein]

49 minutes ago, GoldForest said:

KSP uses multiple cores. It just uses 1 core for physics because of how Unity works and because calculating physics on more than one core could lead to problems. 

Just an addendum. The connected solids physics  is the complex one to do multicore. The movement one is  pretty easy to do multi core (although is light enough that is not really worth). Said that you can  separate each system of components in a different core with no problems. So for example an optimized system  could have a station being processed by one core and the ship you are flying nearby by other, only when they connect they need to offload to the same core.

[K^2]

On 12/24/2022 at 7:42 AM, tstein said:

Just an addendum. The connected solids physics  is the complex one to do multicore. The movement one is  pretty easy to do multi core (although is light enough that is not really worth). Said that you can  separate each system of components in a different core with no problems. So for example an optimized system  could have a station being processed by one core and the ship you are flying nearby by other, only when they connect they need to offload to the same core.

There are three major steps in a physics frame.

1. Find all collisions between objects and create contact points for these.
2. Update constraints and contact forces by solving a linear system of equations.
3. Update positions, rotations, and velocities of all the objects in the scene.

For some definitions, a scene is going to have colliders, which are individual capsules or collision meshes, for example; rigid bodies, which for KSP are basically a component; constrained bodies, like an entire ship made of components; and islands, which are any collections connected by either a constraint or a contact (collision) point.

In terms of being able to split these up, for step 1, you can have each collider be assigned to a separate core. You can do some additional optimization here by assigning affinities to some early branches of the BVH tree, but that's not critical. You really can have as many threads running for that as you can spare and just split the list between them. That said, BVH itself needs some maintenance at least occasionally, and that tends to be a single thread process. Fortunately, that doesn't need to happen every frame.

For the second step, you can do each island in a separate thread. However, in practice, it's more expensive to check for island connections than to simply have one giant physics island. So in practice, in pretty much every physics engine I've worked with, the entire scene is treated as an island, and so has to be processed in a single thread. There are tricks to split that out as well, but they're complicated, and in practice nobody bothers. The optimization that's actually taken is collision cache. Instead of solving the system of equations from scratch, you cache previous frame's result and only compute the difference. That can be done iteratively, and you can often get away with a single iteration of this method per frame. This way, you literally just have to iterate through contact points and constraints and update them. This can be very inexpensive. So the fact that this is a single thread operation isn't usually a bottleneck.

Finally, updating positions and velocities can be done per constrained body - that is, per ship. It's usually a very cheap step anyways, so it might not even make sense to farm out for something like KSP, where you won't have a thousand objects to update. So this might end up being single-thread as well just for simplicity.

All of that said, collision checks are usually the most expensive part, and it's the one that's most readily made parallel. PhysX in Unity did not, which is a big part of why the performance was horrible. I don't know how much of a change this is in KSP2. Modern Unity allows using PhysX or Havok depending on how you set up your components, and we haven't heard any updates about which one KSP2 uses.

[tstein]

13 hours ago, K^2 said:

There are three major steps in a physics frame.

1. Find all collisions between objects and create contact points for these.
2. Update constraints and contact forces by solving a linear system of equations.
3. Update positions, rotations, and velocities of all the objects in the scene.

For some definitions, a scene is going to have colliders, which are individual capsules or collision meshes, for example; rigid bodies, which for KSP are basically a component; constrained bodies, like an entire ship made of components; and islands, which are any collections connected by either a constraint or a contact (collision) point.

In terms of being able to split these up, for step 1, you can have each collider be assigned to a separate core. You can do some additional optimization here by assigning affinities to some early branches of the BVH tree, but that's not critical. You really can have as many threads running for that as you can spare and just split the list between them. That said, BVH itself needs some maintenance at least occasionally, and that tends to be a single thread process. Fortunately, that doesn't need to happen every frame.

For the second step, you can do each island in a separate thread. However, in practice, it's more expensive to check for island connections than to simply have one giant physics island. So in practice, in pretty much every physics engine I've worked with, the entire scene is treated as an island, and so has to be processed in a single thread. There are tricks to split that out as well, but they're complicated, and in practice nobody bothers. The optimization that's actually taken is collision cache. Instead of solving the system of equations from scratch, you cache previous frame's result and only compute the difference. That can be done iteratively, and you can often get away with a single iteration of this method per frame. This way, you literally just have to iterate through contact points and constraints and update them. This can be very inexpensive. So the fact that this is a single thread operation isn't usually a bottleneck.

Finally, updating positions and velocities can be done per constrained body - that is, per ship. It's usually a very cheap step anyways, so it might not even make sense to farm out for something like KSP, where you won't have a thousand objects to update. So this might end up being single-thread as well just for simplicity.

All of that said, collision checks are usually the most expensive part, and it's the one that's most readily made parallel. PhysX in Unity did not, which is a big part of why the performance was horrible. I don't know how much of a change this is in KSP2. Modern Unity allows using PhysX or Havok depending on how you set up your components, and we haven't heard any updates about which one KSP2 uses.

 The  island connections are NOT hard to deal in a game where space between islands is so large like in KSP and where  entities also  tend to move in  monotonic forms relative to each other, that means  temporal coherence is  very large (so you know what  islands are likely or not to interact in the next couple of frames), this is completely different from most other games where the movement patterns  are almost arbitrary and constrained in a heavily populated and spatially dense "scene".  In such scenario a simple  sphere intersection  is  good enough for that  and  has a near zero  cost when you have a non stupid number of islands. (each  compare takes 3 multiplications 5 sums, 3 movups and a branch), In fact a predictive  space bound by a cone aligned with the vector of velocity between the 2 islands (and with its slope based on the combined maximum acceleration of both islands (that can be easily pre computed) is good enough on KSP to decide if an island should be merged or not

The constraint solver is  the vast majority of the intensive physics in kerbal, but the  independent nature of most cells means you  can separate the islands into different cores on the most common scenarios. That is specially useful  because  you are  unlikely to have 2 islands in risk of interaction at the same time when the physics load is at it's highest ( i.e. an island accelerating inside the atmosphere, that is when the engine struggles for most players. That because usually you do not have 2 ships accelerating inside the atmosphere suddenly meet each other ). 

 

Such a separation of cores would mean  that  every common scenario bar the docking connection moment scenario  can be optimized into multiple cores.

[K^2]

47 minutes ago, tstein said:

The  island connections are NOT hard to deal in a game where space between islands is so large like in KSP

Yeah, but it's unlikely to be a bespoke solver. It's likely either PhysX or Havok solver that come with Unity. I am well familiar with the code Havok was based on, and that does not employ multi-island optimization. I have not seen the latest Havok's code myself, so I can't insist they haven't implemented it, but I see no indication they have either.

47 minutes ago, tstein said:

The constraint solver is  the vast majority of the intensive physics in kerbal, but the  independent nature of most cells means you  can separate the islands into different cores on the most common scenarios.

Most of the time you're playing KSP, the only object in the simulation distance is your ship, and that's a single island. Even if you're looking at stage separation, if you treat the main ship and newly separated stage as a single island, your performance is at least as good as it was just before the stage separation, meaning the optimization here doesn't help your worst case.

Likewise, if you are approaching another complex ship, odds are, you're planning to dock. Meaning, as soon as you've docked, you have a single island, and if your performance isn't good enough here, then it doesn't matter that much if the performance drop happened when you got within physics range of the other craft or when the AABBs started to overlap. Either way, you have a more serious performance issue to address.

Because of that, even if we were talking about a bespoke engine, this kind of optimization would be pretty low on a priority list. So even though it's a possible optimization, I doubt heavily that it is taken. I fully expect the solver to still be single core regardless of which option the Intercept has gone with.

Edited December 26, 2022 by K^2

[tstein]

22 hours ago, K^2 said:

Yeah, but it's unlikely to be a bespoke solver. It's likely either PhysX or Havok solver that come with Unity. I am well familiar with the code Havok was based on, and that does not employ multi-island optimization. I have not seen the latest Havok's code myself, so I can't insist they haven't implemented it, but I see no indication they have either.

Most of the time you're playing KSP, the only object in the simulation distance is your ship, and that's a single island. Even if you're looking at stage separation, if you treat the main ship and newly separated stage as a single island, your performance is at least as good as it was just before the stage separation, meaning the optimization here doesn't help your worst case.

Likewise, if you are approaching another complex ship, odds are, you're planning to dock. Meaning, as soon as you've docked, you have a single island, and if your performance isn't good enough here, then it doesn't matter that much if the performance drop happened when you got within physics range of the other craft or when the AABBs started to overlap. Either way, you have a more serious performance issue to address.

Because of that, even if we were talking about a bespoke engine, this kind of optimization would be pretty low on a priority list. So even though it's a possible optimization, I doubt heavily that it is taken. I fully expect the solver to still be single core regardless of which option the Intercept has gone with.

I was more worried on the concept that we will have multiplayer. And surely  we cannot avoid having one process being the master that ensure the physics is synced on both  players.  The 2 players most of the time will be in independent islands. My time in the industry was when we built  new engines for every new game family, there was not many pre made engines outside for FPS games, so my mentality is always of  "well, I would implement that"

[K^2]

9 hours ago, tstein said:

I was more worried on the concept that we will have multiplayer. And surely  we cannot avoid having one process being the master that ensure the physics is synced on both  players.  The 2 players most of the time will be in independent islands. My time in the industry was when we built  new engines for every new game family, there was not many pre made engines outside for FPS games, so my mentality is always of  "well, I would implement that"

Oh, yeah, for MP, you can treat each player's physics radius as its own scene. I have no idea if Unity actually has support for multi-threading parallel scenes, but for any custom engine this would have been an absolute freebie, for sure.

And yeah, I'm one of the relatively few people still specializing in in-house engines. Fewer and fewer studios do this, but also, there aren't a lot of specialists who can jump in and work with a game engine from the ground up, so the pay is still good.

[Gotmachine]

On 12/25/2022 at 11:31 PM, K^2 said:

All of that said, collision checks are usually the most expensive part, and it's the one that's most readily made parallel. PhysX in Unity did not, which is a big part of why the performance was horrible.

Spatial queries and Rigidbody simulation is far from being the main bottleneck in KSP. And PhysX is actually decently multithreaded. There are definitely some inefficiencies both on the Unity side, which doesn't expose some very useful parts of the PhysX API, but mainly on the KSP implementation side.

But all in all, RB and collider physics are objectively the most optimized part of KSP, taking 15-20% of the frame time in part count constrained scenarios. The single-thread bottleneck has no main culprit, it's a combination of an inadequate general architecture and of tons of tiny or not so tiny inefficiencies in all subsystems.

This being said, the main issue with physics in KSP is that a solver primarily made to simulate ragdoll physics is wholly inadequate for the task of simulating a rocket structural integrity. And it can even be argued that the idea of simulating structural integrity out of RBs whose shape and mass is primarily defined by function is a silly idea in the first place.

[Bej Kerman]

22 minutes ago, Gotmachine said:

And it can even be argued that the idea of simulating structural integrity out of RBs whose shape and mass is primarily defined by function is a silly idea in the first place.

It technically wouldn't be rocket science to make an engine that turns rockets into giant soft-body models that warp and explode with stress while maintaining functionality of individual parts...

[K^2]

32 minutes ago, Gotmachine said:

Spatial queries and Rigidbody simulation is far from being the main bottleneck in KSP.

For KSP, absolutely. There is going to be a lot more pressure on physics in KSP2, though. It's a little hard to say exactly how hard Intercept is riding the physics engine in KSP2, but it's clear that they're stepping it up. Continuous collisions have been indicated in one of the blogs, which require more expensive spatial queries, and we don't know exactly how much physics will be done at what levels of warp, but it's clear that physics warp is going to be a more central features. This might be where the "physics LoD" is supposed to come in play, which I'm guessing is the treatment of larger sections of the ship as a single rigid body, but we don't have enough details on that yet. On the net, I expect both more optimization and more usage of the physics system in KSP2.

41 minutes ago, Gotmachine said:

And PhysX is actually decently multithreaded. There are definitely some inefficiencies both on the Unity side, which doesn't expose some very useful parts of the PhysX API, but mainly on the KSP implementation side.

Eh... This is one of the places where the boundaries gets fuzzy. I can certainly query PhysX in parallel job threads, but then do what, disable collisions for the main scene and manually create contact points as joints? I mean, it's possible,  but then I have to manage my own collision cache, since PhysX won't know that these are the same collision points from frame to frame, and at that point, I should probably be using my own solver for it - no need to jam that ugly hack into PhysX. And then to avoid causing hick ups in PhysX, maybe I'll do my own BVH management. Of course, that would require a custom collision broker as well, and then why am I using a PhysX scene at all?

You can replace pretty much every part of Unity with custom parts. You can also make a completely custom engine. That's a lot of work, though. So it's really not fair to say, "It's developers' fault," when Unity's implementation of PhysX is just bad, and would require you to rewrite the entire physics engine to get rid of all the problems.

Admittedly, PhysX gets more crap thrown at it than it deserves for how it's implemented in Unity, but even so, it's a sub-par physics engine, and replacing that with Havok and building a new threading model around that with the ECS was the best way Unity was able to resolve all of that. 

Last time we got any concrete updates on this side of the tech, it sounded like Intercept was still using game objects, meaning they'd be stuck with the old style PhysX simulation. But that could have changed. ECS is becoming a new standard, and isn't that much work to convert to, so it's entirely possible that we're going to be looking at Havok physics, where there is way more flexibility in terms of how things are processed in threads. Plus, a way more stable solver.

[Gotmachine]

You are focusing a lot on collisions and spatial queries, but this is absolutely not a bottleneck even in KSP 1. The only perf issue is RB joints.

Given that ECS is barely out of experimental as we are speaking, I doubt KSP 2 is using anything beside a few specific Burst/Jobs implementations for a handful of subsystems, but maybe we will be surprised.

The very likely scenario is that KSP 2 is using exactely the same implementation as KSP 1 as far as RB physics are concerned, with a slightly smarter "spam RB joints to avoid spring rockets" system and likely some "optimizations" like merging parts as a single RB or making inactive stuff kinematic.

Again, the mistake here is to try to use PhysX RBs for something they can't do. Using Havoc or DOTS physics wouldn't change anything, as they all implement a lagrange multiplier solver that fundamentally can't guarantee that joint limits and drives won't be violated, and are simply not suited for long joint chains with highly variable RB mass ratios. And on a side note, PhysX also has a reduced coordinates solver, which is actually more suited for this kind of stuff. And it would not be that much of an effort to implement all RB physics stuff in a C++ library written on top of PhysX instead of relying on the Unity default wrapper/API.

Time will tell soon, but while I'm relatively optimistic that KSP 2 will be a better foundation than KSP 1, there are many hints that despite what was said, a lot of the core implementations were initially copypasted from KSP 1 without much analysis on if those implementations made sense in the first place. On many aspects, I'm expecting a KSP 1 2.0, not a KSP 2 1.0.

[K^2]

1 hour ago, Gotmachine said:

Again, the mistake here is to try to use PhysX RBs for something they can't do. Using Havoc or DOTS physics wouldn't change anything, as they all implement a lagrange multiplier solver that fundamentally can't guarantee that joint limits and drives won't be violated, and are simply not suited for long joint chains with highly variable RB mass ratios.

I think you're a bit out of date on solvers. Modern Havok solver, which is what's in Unity with ECS, uses an updated flow based on the work of Erin Catto. While the underlying principles are similar, the algorithmic approach is quite a bit different and results in much higher stability for long chains and much better performance. When implemented correctly, you should see no springiness at all outside of extreme mass differences in the chain. That is, if you have two 1T modules hooked up to a 1kg module in between, yes, you'll see problems, though, even these can be tuned out, and if you throw a single strut between the 1T modules, that will go away completely. The bending you see with KSP is virtually nonexistent with the new solver. You literally can slap a single constraint at every logical joint and be fine for most practical cases.

It is also far more performant. I have looked at possible room for optimizations in Crystal Dynamics' implementation (see numerous physics puzzles in reboot Lara Croft games,) and I found no reason to mess with the solver itself. We had thousands RBs with thousands of contact points in a scene for Avengers, with no ill effects. (Avengers' overall performance sucks, but none of that is on physics.) Collision detection was absolutely the limiting factor for complex scenes, and that's the part that is most readily parallelized, so it hasn't made a performance difference either.

If your experience with solvers is PhysX, Bullet, and Havok as it worked around 2017 or earlier, you might want to get a refresher. Physics in modern solvers just isn't done this way. Better examples include Crystal Dynamics' Foundation Engine, which is the first one I'm aware of implementing the new solver for a AAA game, modern implementations of Havok, and Chaos Physics from latest Unreal. The latter was still a bit unstable when I was doing evaluations for it, but that was in early private Beata of UE5, so I'm told these problems got fixed and it should be a good representation. Alternatively, you can go to the source, and see how Erin Catto himself implemented it for Box2D engine.

[Arugela]

I've been having this problem with other games that might have worked on linux except for.... (And has anyone gotten the chance to test it on proton?)

Will this game work on an 1100t phenom? Other games recently would work performance wise, but the instructions set preclude playing the game. I forget the instruction set. But it started being used a gen after the phenom 1100t. I've noticed it's problematic for newer games. Again, even if I could run them otherwise.

And it's still a bad time to update hardware.. At least for me.

Edited December 28, 2022 by Arugela

[GoldForest]

1 hour ago, Arugela said:

I've been having this problem with other games that might have worked on linux except for.... (And has anyone gotten the chance to test it on proton?)

Will this game work on an 1100t phenom? Other games recently would work performance wise, but the instructions set preclude playing the game. I forget the instruction set. But it started being used a gen after the phenom 1100t. I've noticed it's problematic for newer games. Again, even if I could run them otherwise.

And it's still a bad time to update hardware.. At least for me.

KSP 2 will launch on Windows only during EA. 

They mentioned they'd like to bring KSP 2 to Linux, but have no plans to do so during EA. 

As for performance, no one knows. Intercept games has released no information. There's another thread talking about system requirements you might want to check out: