Just why is KSP Physics so slow? (NOT a Rant)

[TheTom]

Ok, this seirously is a question out of genuine interest.

Now, everyone knows the current version of PhysX is - ah "seriously suboptimal" in it's internals and the new one is a lot better.

My problem is another one: How can KSP challenge a core with a 300 part rocket...

...when there are demos where you have thousands of particles simulated in real time?

Being a programmer that never did any physics work - I wonder what the difference here is. I am not accusing Squad of crappy programming - please, this is not a rant. I just have a mental problem moving from 300 parts taxing a core to PhysX demos showing thousands of cubes falling onto a table, so to say. What is it that is eating all this processing power?

THere are also other (simpler) games where you can build spaceships out of cubes (space engineer) and that has no problem with spaceships being a lot larger than 300 parts.

I am quite sure I overlook something - if someone can enlight me?

[xtoro]

PhysX uses the GPU, KSP uses the CPU... GPU's can run many more calculations per second (GFLOPS) and have specific functions for physics calculations (PhysX).

Edited July 7, 2015 by xtoro

[Red Iron Crown]

PhysX uses the GPU, KSP uses the CPU...

PhysX runs on CPUs, too, in fact that is the more common implementation. GPU-accelerated PhysX is the exception rather than the norm. KSP's physics bubble runs PhysX on the CPU.

TheTom, the difference is that independent particles can be easily threaded, they only threadlock when they collide and even then only for the particles colliding. KSP vessels are a set of chained, constrained rigidbodies, the motion of each body is dependent on the others and it is not an easily threadable task. Performance seems to be tied to partcount, and is worse than O(n), perhaps as bad as O(n!)

As I understand it Space Engineer melds the component parts into a single rigidbody for increased performance and rigidity. Such a solution could theoretically increase performance for KSP, but we'd lose the "wobbliness" and individual part destruction. Whether this is a good tradeoff is left as an exercise for the reader, but AFAIK the devs are fairly set on keeping some wobbliness in KSP spacecraft.

[DaMichel]

In your usual particle systems the motion of each particle can be advanced independent of all the others. But with joints between parts, one cannot do that any more and one has to solve the equations of motion of the entire system simultaneously. AFAIK that is quite expensive.

Plus particle systems use mostly point particles so only position degrees of freedom are there. With rigid bodies one has to deal with rotation degrees of freedom, too.

If there are multiple ships in the scene, collision detection is performed in addition to everything else, which is also rather costly.

Edit: Ninjad!

Edited July 7, 2015 by DaMichel

[Arsonik]

PhysX runs on CPUs, too, in fact that is the more common implementation. GPU-accelerated PhysX is the exception rather than the norm. KSP's physics bubble runs PhysX on the CPU.

TheTom, the difference is that independent particles can be easily threaded, they only threadlock when they collide and even then only for the particles colliding. KSP vessels are a set of chained, constrained rigidbodies, the motion of each body is dependent on the others and it is not an easily threadable task. Performance seems to be tied to partcount, and is worse than O(n), perhaps as bad as O(n!)

As I understand it Space Engineer melds the component parts into a single rigidbody for increased performance and rigidity. Such a solution could theoretically increase performance for KSP, but we'd lose the "wobbliness" and individual part destruction. Whether this is a good tradeoff is left as an exercise for the reader, but AFAIK the devs are fairly set on keeping some wobbliness in KSP spacecraft.

What if we could "weld" individual stages together? I'm not talking about the Ubizor mod. That thing was buggy as hell, fun as it was. A stock implementation.. Optional perhaps? A huge construct would still wobble like crazy between stages. But it wouldn't look like fuel tanks are made of paper-mache anymore. And? Lowered part count! I'm sure SQUAD has already considered all the possibilities of full/partial ship welding since Ubizor has been around for quite awhile now and been rather popular. Im not really preaching for or against part welds, but I think this would make a cool stock implementation.

[xtoro]

I came up with a theoretical solution to multithread the physics here: http://forum.kerbalspaceprogram.com/threads/126094-Is-Kerbal-Space-Program-Single-Threaded?p=2032605&viewfull=1#post2032605

(post #15)

Edited July 7, 2015 by xtoro

[TheTom]

Well, thanks so far.

I think KSP would greatly benefit from SOME automatic welding happening. IGnore the wobbleness of the heavy parts - but what about the tons of small stuff that never gets problematic?

I just now watch a capsulre approach Minimus that has 3 lights, 3 parachutes, 4 packs of 6 experiments each (and those are small, the largest is the mistery goo). Right there (including the capsule carrying it all) that is 28 parts to 1

So, if welding brings something - start with the small amounts of stuff that never has an issue. Experiments, RCS ports etc. that do not really factor into the wobble.

That said - Space Engineer is NOT welding the parts together. If you watch

at least you can see how the welding is falling apart quite fast. Or at least they do track damage still on a per voxel level - the colissions do not "destroy" the vessels as much as they damage them (and destory voxels).

So, going down you basically tell me that this is a crap problem with worse than O(n) because threading simply is not possible? Then this is quite a PhysX limitation. It seems some others (engines) can do more here (bullet and I found something about multi threaded rigidbdy using OpenCL on a GPU - though a research paper) - but man, it is quite a limitation.

[Arsonik]

That said - Space Engineer is NOT welding the parts together. If you watch

at least you can see how the welding is falling apart quite fast.

The destruction in that video simply didn't look anything like that in KSP in my opinion.

[Red Iron Crown]

That said - Space Engineer is NOT welding the parts together. If you watch

at least you can see how the welding is falling apart quite fast. Or at least they do track damage still on a per voxel level - the colissions do not "destroy" the vessels as much as they damage them (and destory voxels).

I haven't played SE, but in the video it looks like each vessel is a single rigidbody, a rigidbody that is changed on the fly to represent damage (witness how the ships do not flex at all despite energetic collisions). That's a pretty sophisticated damage model, would be great for KSP to have something similar.

So, going down you basically tell me that this is a crap problem with worse than O(n) because threading simply is not possible? Then this is quite a PhysX limitation. It seems some others (engines) can do more here (bullet and I found something about multi threaded rigidbdy using OpenCL on a GPU - though a research paper) - but man, it is quite a limitation.

Bullet doesn't multithread constrained rigidbody chains afaik, everything I've read about multithreaded implementations is still in academia (and in fairness that is reasonable; few if any games other than KSP use constrained chains for single objects, certainly not chains consisting of hundreds or thousands of rigidbodies).

For better or worse this is what KSP has: A difficult-to-thread model of vessels and an engine that has some limitations. I don't see the game changing engines at this point (maybe if they ever make a KSP 2), best we can hope for is better performance from Unity (which it looks like we'll see to some degree with Unity 5) or possibly some form of stock part amalgamation.

[TheTom]

Again, this was not meant as a rant.... so yes, it looks like rigidbody is a fundamental issue and KSP just goes crazy on it (due to what the game does). So yes, welding would be likely the only solution for that. Damn, would never have thought that this really is that unusual.

Watches something about some racing game that looks amazing in their crashes and the dev blog said their physics engine (for around 20 or so cars) runs with 200 FPS... And crashes are deforming. You are not telling me this is not rigidbody either? I mean, how can you make a car and track deformation and damage zones and NOT simulate the car at least as some parts... But then, O(n2) or something worse means every part counts.

[Vicomt]

On the Space Engineers side, a ship is essentially a cube-grid, damage is done to individual cubes within the grid, running physics calcs for player movement, inertia, limited (weird) gravity, and grid/grid intersections is a whole lot quicker then working on the proper physics we have in KSP.

It's like the difference between linear and quadratic curves, SE's increase of 100x the number of blocks is computationally the equivalent of 10x the number of KSP parts (numbers mangled for the benefit of me not having to do actual maths)

[Red Iron Crown]

I'm not really familiar with the racing game mentioned, but there are a few things that could be happening:

- With multiple rigidbody chains it is relatively easy to have a thread for each chain; in KSP this is of limited usefulness for single vessels but would help with multiple loaded vessels and staging events (and I think this is coming with Unity5). For a racing game with many cars it is much more useful, one thread per car means the load can be spread around multiple cores.

- Using primitives rather than meshes for the colliders can increase performance. In KSP most (all?) parts use meshes for their colliders (both for better accuracy and because the common primitive shapes aren't suitable for most parts). If the components of the racecar (of which there are only a handful, I'd bet) are all using primitive colliders then performance should be better.

- It is possible it is not a rigidbody at all, but instead a single deformable body. I don't know enough about those to comment on the relative performance of modelling them.

[Nigeth]

It would help if the stock game stopped treating vessels as a collection of individual parts and didn't apply physics calculations to any part individually. While this is useful or even necessary for some components it's not for others.

I think the biggest performance gain in stock could come from using a "FAR-like" approach to physics modelling and to replace stock components with procedural parts where apropriate. In that case you wouldn't have to apply your model to a lot of individual wing parts because you can either treat them as/replace it with a single component that you then apply the modelling to.

If we had procedural tanks for example one wouldn't have to build big tanks by stacking smaller ones on top of each other and if we had procedural wings one wouldn't have to build big wings by putting smaller ones together. In that example the physics model would then only have to be applied to one part rather than a collection of smaller ones that pretend to be one bigger part.

[Laie]

For me, it has become a lot worse since heat is a thing.

I expect that multithreading *will* help, at least when it comes to heat. I don't know if and how wobble and thrust can be computed in parallel, but the heat system seems to be independent of the structural system. They should be able to run alongside each other nicely.

The need to make everything pointy has inflated my part counts, big_adapter->small_adapter->nosecone... if multithreading cannot improve the physics situation, Squad should really really consider some means of reducing part count, be it through welding or otherwise.

[11of10]

Regarding procedural parts, you can find some here:

Procedural fairings: http://forum.kerbalspaceprogram.com/threads/39512

Procedural tanks might be here: http://forum.kerbalspaceprogram.com/threads/64117

or here: http://forum.kerbalspaceprogram.com/threads/64118

(not sure exactly)

and some procedural wings here: http://forum.kerbalspaceprogram.com/threads/29862

and the welding of parts: http://forum.kerbalspaceprogram.com/threads/107273

[NoMrBond]

It is possible APEX modules (physics solver extensions) will be supported by Unity in the future (provided those modules support OpenCL), this has been hinted at but not confirmed.

If this did happen mesh deformation and destruction could be handled with the APEX Destruction extension for PhysX

[clivman]

Rigid body physics would improve performance by removing the need for struts(physics calculations are run on all of them too) as well. I vote for that.

[TheTom]

Seriously, if you ask me about that then I think the biggest change would be to structure the ship. The current staging approach gets ridiculous when you carry complex payloads.

Separate the ship and possible dormant payloads. Payloads get recalculated into a welded part with resistance numbers (how much pressure, shock can it handle). Then they are ONE part. Heck, if you WANT you can later run them as separate "units" On separate threads in 5.

So, a launcher with 3 satellites on top would have all the parts of the launcher, and 3 parts - one for each satellite. The satellite either breaks or not. Once the fairing opens or through another event.... then the satellite gets activated and simulated properly.

It also means all the elements of the satellites would not show up in the staging - and that is not really negative.

And for the heat - I also would ask how often that needs to be computed Physics in itself has to be very fine grained, but hat distribution could be handled a lot less often Possibly. What is the old rule for programming? NEVER guess performance, always attach a profiler. Right now it is flow, and I have no idea which part is wasting the performance.

But ok, I got from that thread what I wanted - and that is basically that it seems that I overlooked how crazy complex connected rigid body physics turns with the part count growing. Ouch. I was not aware this is fundamentally one of those really extremely computing explosive problems.

[rkman]

My problem is another one: How can KSP challenge a core with a 300 part rocket...

...when there are demos where you have thousands of particles simulated in real time?

Because PhysX' typical use does not involve all particles (parts) constantly colliding with one another. In KSP adjacent parts are constantly colliding/interacting with one another and that makes for a lot more calculations than particles that mostly just fly through the air on their own and only bounce off a wall or floor a few times.

[tomf]

I believe the purose of the physicsless flag if to effectively weld the parts to their parent and remove the need to run physics on them.

[Sharpy]

BTW, do these thousands of cubes demos run on CPU or on GPU? What is their performance on CPU?

[Temeter]

PhysX runs on CPUs, too, in fact that is the more common implementation. GPU-accelerated PhysX is the exception rather than the norm. KSP's physics bubble runs PhysX on the CPU.

TheTom, the difference is that independent particles can be easily threaded, they only threadlock when they collide and even then only for the particles colliding. KSP vessels are a set of chained, constrained rigidbodies, the motion of each body is dependent on the others and it is not an easily threadable task. Performance seems to be tied to partcount, and is worse than O(n), perhaps as bad as O(n!)

As I understand it Space Engineer melds the component parts into a single rigidbody for increased performance and rigidity. Such a solution could theoretically increase performance for KSP, but we'd lose the "wobbliness" and individual part destruction. Whether this is a good tradeoff is left as an exercise for the reader, but AFAIK the devs are fairly set on keeping some wobbliness in KSP spacecraft.

There is one thing I don't understand: Why can't you just e.g. 'cut' a ship in two pieces and then let two threads (or in reality cores) calculate each half? KSP's tree structure means normally parts only have single connections. Shouldn't it be possible to make some process communicate said connection between the two threads? Maybe it would be somewhat more lenient or slightly lagging behind, but, without coding knowledge, it's hard to imagine what could go wrong in this case.

I mean, if we can communicate a thousand boxes touching between multiple cores, why not a single connection?

Edited July 8, 2015 by Temeter

[Superfluous J]

I just now watch a capsulre approach Minimus that has 3 lights, 3 parachutes, 4 packs of 6 experiments each (and those are small, the largest is the mistery goo).

I didn't see this addressed elsewhere in this thread, sorry if I missed it. Most of those parts are physicsless, which (from 1.0 on) means that their mass is added to the part they're stuck to, not themselves; and (since they introduced the concept to the game) that physics ignores them. Your Minmus probe likely has less than 10 parts in it an could actually just have 3 (probe, fuel, engine) as far as physics is concerned.

[selfish_meme]

What I get confused about is PhysX, originally this was a hardware/software company purchased by Nvidia, and Then Unity 3d uses PhysX as the name of its physics engine, which may or may not be the same thing as apparently Unity upgrades to use PhysX, not the other way around.

[Temeter]

What I get confused about is PhysX, originally this was a hardware/software company purchased by Nvidia, and Then Unity 3d uses PhysX as the name of its physics engine, which may or may not be the same thing as apparently Unity upgrades to use PhysX, not the other way around.

It's the same. NVidia bought Ageia when the crappy physics-cards didn't get anywhere, put PhysX chips on their cards and tried to use it for marketing purposes. Besides the chip, PhysX is a real physics engine. Pretty crappy at the beginning, apparently also too excacerbate the need for special chips and using very inefficient code. It's supposedly quite fine now and used by a number of games as a more general concurrent to engines like Havok. PhysX-effects are still somewhat of a marketing gag, but games like KSP don't even profit by NVidia GPUs. Long story short, Unity licensed PhysX as it's prime physics engine and integrated it into their engine.