Make bases unaffected by physics

[cwriter]

As someone who'd like to build alternative space centers on other celestials (Extraplanetary Launchpads + Karbonite + USI Colonies) the physics strike hard on my CPU when building big bases. However, there's not really a point to have physics on an immobile base other than checking for collisions with other space vessels of any type.

However, glancing at the size of the KSC, I think that the game would benefit from being able to build (bigger) bases on moons, planets and asteroids without having the annoying lag and wobbeling.

I thought of a plan like this:

When renaming vessels, add a checkbox for bases and maybe space stations to make them unaffected by physics or affected by physics as only 1 part while actually keeping the information needed for future physical calculations. Bases will be welded at the points where they touch the ground and will be no or only one part for the physics engine. (Just like the KSC buildings, meaning that you still can crash into them (and maybe destroy them, either through reactivation of the physics or like the KSC buildings), but they won't move.)

What do you think about that? Are there any objections?

cwriter

[TheTom]

You are aware that in the future every rocket/base may run a separate thread and that now the main issue is not the physics but the extremely inefficient resource allocation system? Disabling physics would not eliminate the extreme overhead of handling resources and heat.

[cwriter]

You are aware that in the future every rocket/base may run a separate thread

Moving vessels to different threads is a very temporary solution. Not only that you have to have a CPU with a core count that correlates to the amount of vessels in a 2.5 km radius (which on modern CPUs isn't really an issue, given a standard of 4 cores, but might be a problem for old dual cores), it will also drain a lot of CPU power.

and that now the main issue is not the physics but the extremely inefficient resource allocation system?

What resource allocation system? GC? Well, for that matter, you could as well suggest to increase the GC-cycles on computers with a big ram, but really: It's no clean solution. But without know the sourcecode of the physics engine, the only thing I can tell is: If there is a messy resource allocation (which actually is just allocation of memory in a loop without freeing it at the end of each loop), then not even executing the loop would make the problem disappear as well.

Disabling physics would not eliminate the extreme overhead of handling resources and heat.

Resources? Heat? Are we talking about in-game resources now? Well, I'm pretty sure that the physics take around 50% CPU time each loop as they are 3-dimensional forces to be taken into account while resources can be narrowed down pretty easily. But of course: Without any experiment this is just guessing.

Anyways, you didn't mention any reason why my suggestion is either too complex or is broken by design which leaves me confident.

cwriter

[Red Iron Crown]

Won't this suggestion break being able to dock with bases? I.e. to add new modules or join a craft to it for resource transfer.

[cwriter]

Won't this suggestion break being able to dock with bases? I.e. to add new modules or join a craft to it for resource transfer.

Weren't there physicless parts once, for example the ladders? they also wouldn't affect physics (i.e. air resistance) while still being interactive.

Whether this would break it: I really don't know. Depends on whether resource flows are within the physics function or not. If so, this suggestion would require to add an if-clause to make the physic function exit after the resource calculation.

For the adding of new modules: Well, what has been disabled can be enabled again, thus providing the possibility to land a base, simplify it for the physics engine, land the next part, enabling physics for the main part again and so on. Or, depending on the actual implementation of the physics function, it might as well be no problem at all. If you can just attach a part (this implies working docking ports on a "bricked" base) and the game can just add it to the actual base, just by stiffening the docking port connection and everything on the attached part, it wouldn't even be too hard to implement.

But without any insights to the code or the devs clarifying it's pretty much speculation.

cwriter

[TheTom]

> Resources? Heat? Are we talking about in-game resources now? Well, I'm pretty sure that the physics take around 50% CPU time each loop

That is one thing: Ignorant. It is prooven - also due to bug reports - that resource allocation is brutal. Add 30 batteries to a core and see your frame rate drop to single digits. Pretty much like that.

There is an O(n^2) or worse algo in there that is on top generating a TON of garbage. Turning physics off (which I would totally back for a base that is "anchored" - which can happen though one or multiple anchors that are special parts) would rock. But it will not at all fix any of the performance issues you see now.

Which, btw., where no there long time ago - which prooves it is not physicsl. Once upon a time you could handle 1500 part rockets. Not today.

Do not despair, I was as ignorant as you - which is why I asked at http://forum.kerbalspaceprogram.com/threads/128021-Just-why-is-KSP-Physics-so-slow-%28NOT-a-Rant%29

If you read the thread you get pointed to the proof that it is indeed not the physics being slow. In fact, the Physx engine has a special handling for "non moving" elements. If not written totally crappy, a base would settle into intert state pretty fast - and without input not wake up from it.

The relevant bug report is http://bugs.kerbalspaceprogram.com/issues/5136 - named "Turning on fuel cells causes lag". Get the irony? Not physics - they are always there.

[cwriter]

That is one thing: Ignorant.

[...]

I was as ignorant as you

You should really be careful about your choice of words.

That is one thing: Ignorant. It is prooven (correct spelling: proven) - also due to bug reports - that resource allocation is brutal. Add 30 batteries to a core and see your frame rate drop to single digits. Pretty much like that.

What resource allocation? In-game resources or Computer resources (aka memory)?

There is an O(n^2) or worse algo in there that is on top generating a TON of garbage. Turning physics off (which I would totally back for a base that is "anchored" - which can happen though one or multiple anchors that are special parts) would rock. But it will not at all fix any of the performance issues you see now.

"Or worse" is pretty much invented. You should always directly cite your sources: http://bugs.kerbalspaceprogram.com/issues/5136

Which, btw., where no there long time ago - which prooves [proves] it is not physicsl [physical]. Once upon a time you could handle 1500 part rockets. Not today.

Because the engine can't have changed? It's quite contradictory. If it was only for the resource management, then the same issue should have existed before and, which is easier to prove, 1.5k part-rockets should still be possible today if you don't pack any fuel tanks, batteries and generators on it. Quod est demonstrandum.

If you read the thread [...]

... I can see you confusing NVidia PhysX and the physics loop. That, btw., has nothing to do at all with memory allocations and/or cpu lags if you have an NVidia GPU because PhysX will be executed on the GPU. If you mean a more specific quote, I demand citation. The whole thread is mixed with discussions about NVidia PhysX and the game physics.

In fact, the Physx engine has a special handling for "non moving" elements. If not written totally crappy, a base would settle into intert [inert] state pretty fast - and without input not wake up from it.

I'm making a guess saying you actually have no idea how (real life) physics work. You never ever have "no-moving objects". There can only be a velocity that's 0 _relative_ to another object. However, you always need to take forces into account. For example, if you had a "state" for immobile objects, your spacecraft at KSC would simply lift away to nowhere. Reason: Missing mass acceleration, or simply: Missing gravity. Everything that has immobile objects is just one thing: Disabling physics and attaching the object to another and thus translate accordingly. However, KSP's physics don't seem to behave like that as a Kerbal can slip under a vessel and lift it this way. So, physics still are working and press the vessel to the surface of the celestial you're on.

NVidia PhysX guidelines may apply for most FPS, but they are completely inappropriate for a realism-driven game like KSP.

That being said, KSP most likely doesn't apply physics to the vessels that are orbiting and more than 2.5km away from the player's view. There, there are probably simple elliptic rails the vessels "drive" on to save CPU power.

The relevant bug report is http://bugs.kerbalspaceprogram.com/issues/5136 - named "Turning on fuel cells causes lag". Get the irony? Not physics - they are always there.

Oh sweet lord. Personally, I despise GC-based programming, exactly because of things like this. Minecraft had its problems, now this game has them too. However, the implementation seems pretty messy, especially because this whole problem could be solved by having a list permanently in RAM instead of constantly destroying and recreating it. Nevertheless: You can also see the permanent garbage growth. That shouldn't be coming from graphics, but - you guess it - physics. In this very example, I think it's safe to say that the resource system is about 700% more demanding than the general performance drain. But as I said: In this very example. A vessel consisting of 2 parts of which one is a fuel cell will most likely result in different conclusions. But that all needs to be experimentally verified.

Also, making rigid bodies out of bases would reduce the wobbeling with large bases consisting out of structural parts mostly. And that, my friend, will most likely result in higher FPS.

cwriter

[Red Iron Crown]

... I can see you confusing NVidia PhysX and the physics loop. That, btw., has nothing to do at all with memory allocations and/or cpu lags if you have an NVidia GPU because PhysX will be executed on the GPU. If you mean a more specific quote, I demand citation. The whole thread is mixed with discussions about NVidia PhysX and the game physics.

That's because Unity uses PhysX as its physics engine for the off-rails physics bubble. PhysX is a general purpose physics engine that can run on CPU or GPU. Running on the GPU is not enoabled on the current version of PhysX that KSP uses, nor should it as the type of physics used (chained constrained rigidbodies) does not thread easily and it thus limited to a single thread per chain (a single vessel is a chain). So running it on the GPU would have lower performance because it could only use a single shader unit, which is much less powerful than a single CPU core. U5 will bring multithreading, but it is expected that for KSP this will be one thread per vessel in the physics bubble at best. GPU PhysX is better suited for large numbers of independent objects that only interact when colliding with each other (think of some object exploding into hundreds or thousands of pieces of debris).

[cwriter]

That's because Unity uses PhysX as its physics engine for the off-rails physics bubble.

PhysX can be used in various ways. PhysX requires a lot of coding to be used inside a game engine. And then, the interface there matters as well since you need to handle your actors to the physics engine. It's not as simple as "I use PhysX, it does the magic by itself". And that's where you can win or lose your CPU time.

Running on the GPU is not enoabled on the current version of PhysX that KSP uses, nor should it as the type of physics used (chained constrained rigidbodies) does not thread easily and it thus limited to a single thread per chain (a single vessel is a chain).

http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/Advanced.html

You have many junctions that can be parallelized easily. Same goes for drag and lift. I'm confident that it is indeed possible to write the multithreading part, however, I can not determine the effort required to do so without actually having insights. The devs are setting other priorities though. Things that cause huge lags? Priority: Low

So running it on the GPU would have lower performance because it could only use a single shader unit, which is much less powerful than a single CPU core.

Agreed, but that can't be used as defense. There are lots of games out there that manage to parallelize their physics. Might well be that it wasn't Squad's main priority, but it should have been.

GPU PhysX is better suited for large numbers of independent objects that only interact when colliding with each other (think of some object exploding into hundreds or thousands of pieces of debris).

GPU PhysX is nothing else than just moving matrizes to the CUDA cores on the GPU, calculating stuff there and moving it back to the CPU. You can't have PhysX running entirely on the GPU due to the fact that the data mostly relies in the RAM and needs to go through the bus to the CPU and then to the GPU. You can simply "outsource" some calculations.

Back to topic:

A base that doesn't require physical interactions, shouldn't drain performance for that matter. The "safer" a base gets (and thus inaffected by some "fall through the surface of the celestial"-bug), the better.

cwriter

[Red Iron Crown]

PhysX can be used in various ways. PhysX requires a lot of coding to be used inside a game engine. And then, the interface there matters as well since you need to handle your actors to the physics engine. It's not as simple as "I use PhysX, it does the magic by itself". And that's where you can win or lose your CPU time.

Of course. I was mostly correcting the idea that KSP's physics runs on the GPU with NVidia cards (it doesn't) or that KSP doesn't use PhysX as a core component of its physics engine (it does).

http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/Advanced.html

You have many junctions that can be parallelized easily. Same goes for drag and lift. I'm confident that it is indeed possible to write the multithreading part, however, I can not determine the effort required to do so without actually having insights. The devs are setting other priorities though. Things that cause huge lags? Priority: Low

They are not easily parallelized, because the motion of each rigidbody affects all the other bodies and joints down the line. Drag and lift are similar, they are dependent on AoA, thus position, thus the motion of the body and we're back to the first statement. There are some things that could be broken out more easily into their own threads though, like heat and resource flow.

Agreed, but that can't be used as defense. There are lots of games out there that manage to parallelize their physics. Might well be that it wasn't Squad's main priority, but it should have been.

Point me to a game that uses chained rigidbodies to the extent that KSP does. The games that parallelize their physics are those that have more easily threaded models, like a pile of unconnected rigidbodies colliding with each other in an explosion as an example.

GPU PhysX is nothing else than just moving matrizes to the CUDA cores on the GPU, calculating stuff there and moving it back to the CPU. You can't have PhysX running entirely on the GPU due to the fact that the data mostly relies in the RAM and needs to go through the bus to the CPU and then to the GPU. You can simply "outsource" some calculations.

Well yes, but my point is that it only makes sense to move the calculations to the massively parallel GPU when the physics are easily threaded in the first place.

[Kaos]

I would be more for ground constructions. That is you have some different buildings you can construct, given the right ressources (might be also parts of ships you have brought) and enough crew. These buildings would be handled the same way KSC is handled.

[cwriter]

[...]or that KSP doesn't use PhysX as a core component of its physics engine (it does).

I never doubted that NVidia PhysX are part of the game physics. It's just not to be used synomymous and/or you can't blame everything on NVidia.

They are not easily parallelized, because the motion of each rigidbody affects all the other bodies and joints down the line. Drag and lift are similar, they are dependent on AoA, thus position, thus the motion of the body and we're back to the first statement. There are some things that could be broken out more easily into their own threads though, like heat and resource flow.

Let's get away from motion for a second, for the motion really can't be parallelized. But what can be parallelized, are the forces. In a simple example you might have 3 tanks joint, the first of which has wings attached. Then, you can calculate the forces for each segment specifically. In a horizontal flight, the wings will of course result in a force pointing normal to the planes' orientation. The force that applies on the wings can be calculated and cross-checked with the surface attach point force tolerance. If it doesn't exceed the limits, you can simplify the force by putting the two forces together to their balance point. That all in a different thread, to be duly noted.

Then, the only thing you still have to do, is to check the junctions. Look at the forces that occur on the part with the wings, then at the forces of the middle part. All forces will be more or less the same, with the exception of:

- Air resistance

- Lift

So, there will be a force on the junction of compression and vertical difference. If that exceeds the limit: Break; otherwise go on.

The last part, however, has the same forces as the middle part. The only things that add to it are the compression and, maybe, the forces that apply during the breaking up.

In the end of course, you still need to serially multiply the forces with the delta time and display everything, but as you can see, you can parallelize a huge lot of things.

I agree on heat and resource flow though.

Point me to a game that uses chained rigidbodies to the extent that KSP does. The games that parallelize their physics are those that have more easily threaded models, like a pile of unconnected rigidbodies colliding with each other in an explosion as an example.

Well, there is no game built exactly as KSP, but there are a lot of games dedicated to physics.

- Rigs of Rods (and it's child, BeamNG)

- Space Engineers and Medieval Engineers (altough they seem to cheat a bit)

However, I don't know the internals of every game, neither do I know every game out there.

Well yes, but my point is that it only makes sense to move the calculations to the massively parallel GPU when the physics are easily threaded in the first place.

See above. You can discuss about the word "easily" for sure, but it's certainly not impossible.

Back to Topic:

I would be more for ground constructions. That is you have some different buildings you can construct, given the right ressources (might be also parts of ships you have brought) and enough crew. These buildings would be handled the same way KSC is handled.

That's an idea as well.

I see some objections though:

- You need to have pre-created buildings, meaning that you can't be as creative as you might want to be and it will stress the devs even more.

- It would certainly break something in the realism if you didn't have to resupply the stations, except if you mean something like planting a flag for a colony which provides an interface similar to the one of KSC where you can build life support facilities.

However this would take the charme of building your very own, personalized base. It's worth discussing, though.

cwriter

Edited July 25, 2015 by cwriter

[Red Iron Crown]

I never doubted that NVidia PhysX are part of the game physics. It just not to be used synomymous and/or you can't blame everything on NVidia.

I think you underestimate PhysX's role in the realtime physics in KSP, to be honest. The whole point of using a third party engine is to not have to write the physics model from scratch. KSP is very much dependent on Unity for updates to the physics model, which is why the move to Unity 5 is so promising and exciting.

Let's get away from motion for a second, for the motion really can't be parallelized. But what can be parallelized, are the forces....

The motion of the connected bodies apply forces to the other bodies. This is not as simple a problem as you make it out to be.

In the end of course, you still need to serially multiply the forces with the delta time and display everything, but as you can see, you can parallelize a huge lot of things.

This means the computationally easy part is parallelized while leaving the computationally hard part as is. I would not expect much in the way of performance gain from this.

Well, there is no game built exactly as KSP, but there are a lot of games dedicated to physics.

- Rigs of Rods (and it's child, BeamNG)

- Space Engineers and Medieval Engineers (altough they seem to cheat a bit)

However, I don't know the internals of every game, neither do I know every game out there.

Rigs of Rods treats vehicles as a single softbody (with a few other connected bodies for the wheels). Computationally equivalent to a KSP craft with half a dozen parts plus the softbody calcs (not sure how complex they are).

Space Engineers appears to treat each vessel as a single rigidbody for motion, with a voxelized damage model. This is also much less computationally expensive than KSP's model.

[TheTom]

I think one area everyone overlooks is: get rid of rigidbody for a base Voila, instant paralellisability.

How?

* A base is constructed of modules. Modules which are landed independently Most bases will be build from modules landed in multiple independent operations, that later get combined.

* They are connected. Now, instead of making them one rigidbody, assume the connectivity is not rigid but quite flexible within limits. Some sort of expandable tube. One that within certain limits does not really exert force to both sides (or: extremely little which can be ignored).

* On top you can provide achor parts that can activate on the surface and use a strong force to anchor their module. So no more "moving the base with a little rover crash". This and good spring programming will make pretty much most modules inert - i.e. the physx engine can cheat because the forces are in equilibrium. For an anchored object you basically can even ignore calculating gravity

If you trick with those parts smart you can at least paralallize a base, and can mostly turn physx totally off for most modules until something crashes into them.

[WinkAllKerb'']

close thread (+ approx lock {partial sim}); proxy "conditionnal()" detect ; reopen thread.

balance and equilibrium as always. might worth some brainstorming around ...

(thread or sub loop //) it's the same just managed another way "how too mutlithread in monothread // cpu // gpu // etc." and why nowdays we have mutlithread core vs some years ago

Edited July 26, 2015 by WinkAllKerb''

[Glaran K'erman]

I don't understand anything here

[RoverDude]

As a fellow who's spent significant time working with bases... rest assured, just flagging them to ignore physics does not quite work

[WinkAllKerb'']

hehe just some thoughts around vrage, (grid approach), un/merging, sensor and a bunch of related updates like the (status switch one) // with some ksp already existing thing ; )

i wonder if some similar process could be applied/enhanced to/in ksp and unity in some way regarding thoose kind of memory consumption/structure & stability concern while switching scene, warping etc. (probably could be applied not limitative to base physics within the game at some point sort of handy workaround more or less regarding the fact ksp do not use grid based calculation engine )

station/small ship/large ship hierarchy* approach i mean

My own bet is that it could be some good inspiration as a basis to explore for some potential further enhancement with some of the said "grid" related process translated/applied to ksp/unity ""non grid/nodal"" engine layers*. ; )

Edited July 26, 2015 by WinkAllKerb''

[pincushionman]

As a fellow who's spent significant time working with bases... rest assured, just flagging them to ignore physics does not quite work

What about changing them into the same kind of objects as the KSC models? These are static, yet they can still be interacted with in the flight scene (building destruction).

[Alshain]

What about changing them into the same kind of objects as the KSC models? These are static, yet they can still be interacted with in the flight scene (building destruction).

You can't change a dynamic craft into a static model. Static models are built in art programs like Blender. That is why they are static. The best you can do is a weld mod to reduce part count.

[Captain Sierra]

hehe just some thoughts around vrage' date=' (grid approach), [i']un/merging, sensor and a bunch of related updates like the (status switch one) // with some ksp already existing thing ; )

i wonder if some similar process could be applied/enhanced to/in ksp and unity in some way regarding thoose kind of memory consumption/structure & stability concern while switching scene, warping etc. (probably could be applied not limitative to base physics within the game at some point sort of handy workaround more or less regarding the fact ksp do not use grid based calculation engine )

station/small ship/large ship hierarchy* approach i mean

My own bet is that it could be some good inspiration as a basis to explore for some potential further enhancement with some of the said "grid" related process translated/applied to ksp/unity ""non grid/nodal"" engine layers*. ; )

THe problem with Space Engineers' grid approach as it relates to KSP is all armor blocks are merged into a single voxel mass and the entire ship acts as a single rigid body. There is no simulation of force between two blocks of a grid. The simulation of part-part stresses and the challenges that presents are a key feature of KSP. If I were to put this station core onto a rocket without struts, it'd fold in half and thats a realistic design consideration. Under SE's grid system, that wouldnt be the case.

[WinkAllKerb'']

yup yup.

that's why i tend to think something like that could be interesting at some point to be further enhanced & balanced (and totally aside from the voxel aspect):

high distance // sort of grid intermediate rigid simulation @ intermediate distance /(& eventually tweakables here (@max/min dist & @on/off ) for thoose interested in)/ active non active vessel "very" close then full simulation

was mostly thinking also to some part of existing code within ramon(&co.) and romfarer(&co.) (&othersalike) work related to active / non active vessel or body distance calculation to each other.

EDIT: also in // with kraken(s) spotting , & smaller broken sim. and stranges trajectories results & etc. that happen time to time. This might/could allow to solve some of thoose aspects.

Edited July 30, 2015 by WinkAllKerb''

[cwriter]

I think you underestimate PhysX's role in the realtime physics in KSP, to be honest.

Might well be. Might also not. Post some source code and we can discuss it.

The whole point of using a third party engine is to not have to write the physics model from scratch.

Yes, but yet again: It always depends on implementation and/or correct/appropriate use. You can also have a ferrari and only drive it in the first gear.

KSP is very much dependent on Unity for updates to the physics model, which is why the move to Unity 5 is so promising and exciting.

I don't know. I don't expect too much from u5 ksp.

The motion of the connected bodies apply forces to the other bodies. This is not as simple a problem as you make it out to be.

Motions don't apply forces. Accelerations apply forces to a mass, according to F=m*a. Velocity has nothing to do with forces. Thus velocity does not have to be calculated before drawing anything, despite on collisions, as you have to get the impact brake forces out of a velocity.

This means the computationally easy part is parallelized while leaving the computationally hard part as is. I would not expect much in the way of performance gain from this.

Again: Without proper facts, this is speculation.

Rigs of Rods treats vehicles as a single softbody (with a few other connected bodies for the wheels). Computationally equivalent to a KSP craft with half a dozen parts plus the softbody calcs (not sure how complex they are).

Even Rigs of Rods with that "easy" physics model as you point it out to be supports threading. KSP doesn't. Without threading, Rigs of Rods may lag too depending on CPU power.

Space Engineers appears to treat each vessel as a single rigidbody for motion, with a voxelized damage model. This is also much less computationally expensive than KSP's model.

Yeah, but there are lots of physics interactions anyways (debris, ores etc.).

I hope you didn't expect me to find a game exactly like KSP.

As a fellow who's spent significant time working with bases... rest assured, just flagging them to ignore physics does not quite work

I really appreciate your mod work, however, I have to state that beliefs belong to religions. Can you elaborate? What does work then?

You can't change a dynamic craft into a static model. Static models are built in art programs like Blender. That is why they are static. The best you can do is a weld mod to reduce part count.

Of course you can. You still have vertices, remember? You will probably lose most functionality, though.

THe problem with Space Engineers' grid approach as it relates to KSP is all armor blocks are merged into a single voxel mass and the entire ship acts as a single rigid body. There is no simulation of force between two blocks of a grid. The simulation of part-part stresses and the challenges that presents are a key feature of KSP. If I were to put this station core onto a rocket without struts, it'd fold in half and thats a realistic design consideration. Under SE's grid system, that wouldnt be the case.

SE isn't really opting for realism. KSP does a good job simulating rockets, but tell me: Is there any point in running a whole physics loop over a base that doesn't have engines/RCS/Reaction wheels (anything that can produce force) and doesn't or shouldn't move relative to the surface?

cwriter

[TheTom]

I think that is the point. A base - once "settled" is static. Point is, though, PhysX has special dcode for that (and that is goingto be better in the new version - the old one is inefficient is there are no forces to many objects). Problem is - the performance issue is not PhysX, it is the rest. Resources (electricity etc.) is done extremely inefficient