[WIP][1.8.1, 1.9.1, 1.10.1, 1.11.0–2, 1.12.2–5] Principia—version ‎‎Kronecker, released 2024-11-01—n-Body and Extended Body Gravitation

[MAKC]

Do you accept donations?

[eggrobin]

I'll try making a dedicated renderer class and adding it as a component of MapView.MapCamera.gameObject like Cilph, since his code works (and he seems to have a clue about how Unity works).

That worked!

The specifics of the solution: Have a class T inherit MonoBehaviour, call MapView.MapCamera.gameObject.AddComponent<T>() in your addon's Start() and do the redraw in T.OnPreCull().

Edited February 8, 2014 by eggrobin

[eggrobin]

Cross-posting from the OP:

I fixed a bug or two since 2014-02-05, added a few TODOs, but have not cleaned up the code to any measurable extent. I am, however, publishing it on GitHub (under the MIT license).

Caveat Compilator: As previously stated, this is just a proof of concept with a bunch of traces. Pressing the wrong buttons in the wrong order will result in lots of NullReferenceExceptions and off-rails crafts will behave weirdly. Using HyperEdit to set up initial conditions, then switching to Newtonian physics and fooling around with reference frames can be entertaining though.

You might learn something from looking at the Integrators part (which admittedly contains only one integrator), the rest was quickly hacked together, has no tests, is badly structured &c.

Now that I have fixed trajectories lagging, the next step is going to be handling off-rails stuff. This is going to be interesting. Does anybody know if there is a way to find the acceleration on a vessel excluding gravity and reference frame weirdness?

[landeTLS]

Cross-posting from the OP:

Now that I have fixed trajectories lagging, the nex is going to be handling off-rails stuff. This is going to be interesting. Does anybody know if there is a way to find the acceleration on a vessel excluding gravity and reference frame weirdness?

Ooo. This should be fun. Ill compile this later and Give it a go. I have no idea how to accomplish the acceleration retrieval thing.

Edited February 8, 2014 by landeTLS

[NathanKell]

Not sure about reference frame weirdness, but you can try grabbing vessel.acceleration - vessel.flightintegrator.gForce?

[eggrobin]

Not sure about reference frame weirdness, but you can try grabbing vessel.acceleration - vessel.flightintegrator.gForce?

Is gForce the gravitational force, or the nongravitational acceleration (the acceleration that is seen on the g-meter)?

The name g-force is just terribly confusing, as it typically refers to the difference between the acceleration and the acceleration due to gravity...

I think there's some Coriolis stuff in the vessel.flightintegrator, so that counts as reference frame weirdness.

Also, what about torque?

Anyway, it's 6 in the morning for some reason, so I'll get some sleep.

Edited February 8, 2014 by eggrobin
It's so la'te I can't plac'e apo'strophes pro'perly. Also, 'the from with the' makes little sense.

[NathanKell]

Ok, then you just want vessel.geeforce * 9.81 (for m/s). That is total acceleration - centripedal and coriolis effects - gravity.

FlightIntegrator.gForce, despite its name, is current gravitational acceleration.

Not sure about torque.

[bulletrhli]

Are you going to be releasing a very alpha version of this for people to try anytime soon?

[MAKC]

Are you going to be releasing a very alpha version of this for people to try anytime soon?

It's been answered multiple times.

[drtedastro]

Just found this. Good luck, and please keep pressing on.... This will be good...

[bulletrhli]

It's been answered multiple times.

My apologies for not reading every single comment through the many pages of this thread. I have failed all of the KSP community. I am sorry. Forgive me.

[MAKC]

My apologies for not reading every single comment through the many pages of this thread. I have failed all of the KSP community. I am sorry. Forgive me.

You only had to read the 1st post tho..

[eggrobin]

PSA: the 'Simulator' project probably won't compile, it's leftover from my Alternis simulations. It's not needed.

Ok, then you just want vessel.geeforce * 9.81 (for m/s). That is total acceleration - centripedal and coriolis effects - gravity.

FlightIntegrator.gForce, despite its name, is current gravitational acceleration.

Not sure about torque.

Alas, that's a scalar (it's the norm of total acceleration - acceleration from fictitious forces---I'm counting gravity as a fictitious force, even though I'm not implementing GR; it's just more convenient terminology).

I think I found the answer though.

Are you going to be releasing a very alpha version of this for people to try anytime soon?

From the OP (I'm not assuming people will read the entire thread, but I am assuming they'll read the OP),

Expect a slow development cycle, due to a combination of laziness, exams, and this actually being a complicated project.

This is currently hardly more than a proof of concept.

I am, however, publishing it on GitHub (under the MIT license).

So if you want to look at the current prototype you can pull the source from GitHub and compile it; don't expect it to be playable soon (the current state is not an alpha; it's a messy way of generating nice screenshots). Once this is done, you too can generate nice screenshots!

(I guess you can use it to get a feeling for what N-body trajectories look like, but it's highly likely that the current plotting is a bit off.)

As far as providing the DLLs directly, configuring Git to do that without risking to accidentally publish a KSP assembly is more work than I want to do at the moment. Ask around if you don't know how to build from source.

[mic_e]

OK, I just downloaded and tried it, and have a few points to say:

- It works like a charm; I congratulate you. Despite you saying that it is a 'proof of concept', I think that this is very much usable, and would use it in my current gamesave, weren't it for the next point:

- I didn't expect it to actually do n-body physics for the _planets_ as well as the craft... poor Vall. You might want to add an option to do the classical Keplerian math for Bodies, or a Minmus mission might end up being a Near-Kerbin-Asteroid mission. In addition, this would save loads of CPU time.

- It was kind of a pain to build with MonoDevelop, having to hack the sln and csproj files and manually select Mono 4.0 as the toolchain for every project...

[mossman]

So if n-body simulation for celestials is planned (awesome if it is), do you plan on re-arranging them into actual stable orbits (so that vall etc don't just get flung off after a few years).

[eggrobin]

OK, I just downloaded and tried it, and have a few points to say:

Thanks for taking the time to do that!

- It works like a charm; I congratulate you. Despite you saying that it is a 'proof of concept', I think that this is very much usable, and would use it in my current gamesave, weren't it for the next point:

Well, if you were to use it to play, you would find that rockets are useless when using Newtonian physics: when the craft goes off-rails it uses stock physics, and when it goes back on-rails everything that happened off-rails is ignored. In order to play you'd have to 'Switch to Keplerian' for each burn... Don't worry, I'm working on this right now.

It feels like I have to handle just about everything Unity is supposed to do... A problem with game physics engines is that they are terrible at physics.

- I didn't expect it to actually do n-body physics for the _planets_ as well as the craft... poor Vall. You might want to add an option to do the classical Keplerian math for Bodies, or a Minmus mission might end up being a Near-Kerbin-Asteroid mission.

I'd prefer to keep the planets under N-body physics for several reasons.

In addition, this would save loads of CPU time.

This is the first reason: it's the other way around; it would actually be slower to perform the integration with planets on Keplerian orbits (I'll explain later).

The second reason is that I can probably tweak the initial conditions a bit to make things stable. If Scott Manley (illectro)'s intuitions are verified, interpreting the orbits as around the barycenter would fix things, otherwise I might have to tweak the masses a bit, but it should be doable (after all, it works for Jupiter).

The third reason is that I would lose symplecticity (I'll explain later).

The fourth reason is that if the bodies followed the Keplerian approximation (orbiting the primary as in stock rather than the barycenter), Lagrange points and other interesting features of the CR3BP/ER3BP wouldn't work as they should.

- It was kind of a pain to build with MonoDevelop, having to hack the sln and csproj files and manually select Mono 4.0 as the toolchain for every project...

I don't think I can help, I use VS2013. Feel free to fork and maintain a branch with your modified solution and project files for the people out there who use MonoDevelop. Building from source is only going to get harder when I get to optimisation, you'll have to install clang.

I'll explain later.

Okay, it seems not everyone on this thread (and no-one at SQUAD) is really familiar with numerical integration. For the sake of everybody's sanity, I think I'll make a short series of posts roughly explaining Hamiltonian mechanics, RK and SPRK integrators, as well as the Kepler problem (which is more complicated than it looks) and the Saha & Tremaine integrator. Can I get a rough idea of where to start?

In particular, can I assume that people know what a derivative is? Otherwise, can an engineer or physicist tell me how I should explain basic calculus? The best approach would be to start with point-set topology, but in the interest of brevity and not boring everyone to death, 10 posts about the properties of Hausdorff spaces would not be the best way to start.

EDIT: Added a poll for those purposes.

Edited February 8, 2014 by eggrobin

[Ledenko]

Forgive me if I'm asking a stupid question, but could any part of this solution be used to improve the accuracy of stock float physics? I'm excited about n-body physics, but I'm also having fun with stock physics except for the inaccuracies.

[eggrobin]

Forgive me if I'm asking a stupid question, but could any part of this solution be used to improve the accuracy of stock float physics? I'm excited about n-body physics, but I'm also having fun with stock physics except for the inaccuracies.

To some extent, yes. I'll be managing the movement of the center of mass of every vessel in space (maybe in the atmosphere too, the ground looks hard however). It looks like this mod is not going to be too friendly on compatibility though (grabbing precise enough accelerations is hard, I'll have to get the forces from the engines/RCS/&c. directly), so compatibility with any module that exerts thrust will have to be implemented through a plugin.

Edited February 8, 2014 by eggrobin

[Faark]

stock physics except for the inaccuracies.

Is it rly that inaccurate? I only have problems with stock orbital mechanics in two specific situations:

- SOI transitions. The game should use sth like the patched conics there, since currently a high timewarp can screw the intended orbit. The system should not just patch orbits from different SOIs together but also stuff like aerobreak-segments (when entering atmosphere)

- GoOnRails / GoOffRails... this isn't very accurate and starting & stoping timewarp has a messurable effect on your orbit (the forces are not correctly aggregated, presumably). I'm not sure that this N-Body mod as currently planned would automatically fix that.

It looks like this mod is not going to be too friendly on compatibility though (grabbing precise enough accelerations is hard, I'll have to get the forces from the engines/RCS/&c. directly), so compatibility with any module that exerts thrust will have to be implemented through a plugin.

Wow, that doesn't sound very efficient. I always thought KSP stores way more temporary data from internal calculations in variables as necessary. Non of the stuff in vessel like .acceleration, .perturbation, .geeForce, .geeForce_immediate or sth in vessel.flightIntegrator is of any use to get the stock orbital forces?

[eggrobin]

Is it rly that inaccurate? I only have problems with stock orbital mechanics in two specific situations:

- SOI transitions. The game should use sth like the patched conics there, since currently a high timewarp can screw the intended orbit. The system should not just patch orbits from different SOIs together but also stuff like aerobreak-segments (when entering atmosphere)

- GoOnRails / GoOffRails... this isn't very accurate and starting & stoping timewarp has a messurable effect on your orbit (the forces are not correctly aggregated, presumably). I'm not sure that this N-Body mod as currently planned would automatically fix that.

Wow, that doesn't sound very efficient. I always thought KSP stores way more temporary data from internal calculations in variables as necessary. Non of the stuff in vessel like .acceleration, .perturbation, .geeForce, .geeForce_immediate or sth in vessel.flightIntegrator is of any use to get the stock orbital forces?

It's all very unstable, look at the drift of the apoapsis/periapsis when out of warp (including the data from .perturbation, which wobbles around 1e-5 when it should be 0, and is actually an average. .geeForce_immediate wobbles a lot more, with peaks above 1 g0 when it should be 0). This is probably all coming from Unity physics.

The question is not really efficiency (this is completely negligible compared to the other things I have to do) but compatibility: for every module that applies an external force in space, I need to have code that grabs the force (in stock, I think this is ModuleRCS, ModuleEngines, ModuleEnginesFX; can anyone think of what I'm missing in this list?).

Physics engines are not made to handle physics: no-one cares if your bullets are slightly too energetic or pick up angular momentum in a first-person shooter.

Edited February 8, 2014 by eggrobin

[Tyrador]

Is orbit on second image real? What is the name for it? Thanks

[eggrobin]

Is orbit on second image real? What is the name for it? Thanks

The orbit on the second image is the same as the one on the first image. It's just a Kerbin-Synchronous Orbit (KSO).

The weird shape comes from the choice of reference frame: as seen in a nonrotating Kerbin-centric reference frame (say, somebody standing on a pole of Kerbin rotating as the day goes by to always look at the same distant star) it's just an ellipse (the cyan line, as predicted by stock), but as seen in the rotating reference frame (by an observer on the equator of Kerbin, looking up), it's this sort of figure-eight (it's an analemma).

[mic_e]

Well, if you were to use it to play, you would find that rockets are useless when using Newtonian physics: when the craft goes off-rails it uses stock physics, and when it goes back on-rails everything that happened off-rails is ignored.

oh...

The second reason is that I can probably tweak the initial conditions a bit to make things stable. If Scott Manley (illectro)'s intuitions are verified, interpreting the orbits as around the barycenter would fix things, otherwise I might have to tweak the masses a bit, but it should be doable (after all, it works for Jupiter).

Tweaking the masses would heavily distort the balance of the game. I believe the Jupiter system is stable because of orbital resonances, so adjusting the orbital periods of Vall and Tylo might work out.

Minmus's orbit however is simply outside of Kerbin's Hill sphere - I don't see any reasonable way of getting it to orbit properly; at best, you might be able to put it in orbit around a Kerbin-Kerbol Lagrange point...

Experiments will have to show whether you get a solution that stays stable for the full 80 or so years that KSP spans.

It would actually be slower to perform the integration with planets on Keplerian orbits

Well... from my computer scientist's point of view, it would eliminate the quadratic asymptotic dependency on B, but I have a hunch at why your integrators would get a lot of extra work to do.

I think I'll make a short series (...) In particular, can I assume that people know what a derivative is?

Feel free to do a series of `lectures`, I'm quite interested in the topic. I do know basic calculus, and I think you should take that as a prerequisite... I've written a few n-body simulations myself (using the 'trivial' approach of v += a*dt, x+= v*dt), and I have a hunch on how RK improves on that.

Feel free to fork and maintain a branch with your modified solution and project files for the people out there who use MonoDevelop

I don't really like C#, and even less its IDEs; I just view them as a neccesary evil when dealing with KSP, so I don't think I'd be the right person to maintain such a fork.

I need to have code that grabs the force (in stock, I think this is ModuleRCS, ModuleEngines, ModuleEnginesFX; can anyone think of what I'm missing in this list?)

Decouples, docking ports and EVA jetpacks provide force, too. As do collisions between ships.

Also, don't forget that decoupling while rotating or the pumping-around of fuel will affect your orbit, too (the latter is a bug, though).

I think the main cause for fluctuations in stock orbits are just due to the fact that the orbit is not calculated for the CoM, but the center of control, so the slightest rotations of the craft are displayed as g forces. While the craft is non-rotating, the stock integrator is working pretty well for me.

If you'd attempt to re-do all those physics, I think you'd basically end up re-writing unity's physics engine, in the process introducing an uncountable number of new bugs, so I heavily recommend against doing that¹.

¹ I think that KSP should indeed be re-written with a from-scratch physics engine in C++, preferrably using fixed-point 64-bit integers for all positions and velocities, but I think that would require an immense amount of work and is entirely unrealistic at the moment.

Edited February 8, 2014 by mic_e

[Faark]

It's all very unstable, look at the drift of the apoapsis/periapsis when out of warp (including the data from .perturbation, which wobbles around 1e-5 when it should be 0, and is actually an average. .geeForce_immediate wobbles a lot more, with peaks above 1 g0 when it should be 0). This is probably all coming from Unity physics.

The question is not really efficiency (this is completely negligible compared to the other things I have to do) but compatibility: for every module that applies an external force in space, I need to have code that grabs the force (in stock, I think this is ModuleRCS, ModuleEngines, ModuleEnginesFX; can anyone think of what I'm missing in this list?).

All true (sounds kinda like the On/OffRails problem), but how to fix it? What about drag? Collisions? Decoupling? Acceleration by exhaust produced by other engines? Sounds like you would have to re-implement the entire physics engine and most other stuff in KSPs. And no, i ofc can't offer any good solution. Is precision that important while the vessel is off-rails? (Yea, I'm looking forward to read about the math involved as well )

[BrianMcNett]

Hooray!

A Hybrid N-Body Symplectic Integrator for Kerbal Space Program was my Christmas wish!

I'm neither enough of a programmer, nor enough of a mathematician to make it happen myself, just smart enough to know the limitations of patched conics and planets/ships on rails, and that there *is* a solution that gives you n-body physics. I can follow the math up to a point, and understand the implications, but that's about it.

So, I'm quietly sitting here, and my brain is going "YES! YES! YES! OMG YES!"

Thank you for taking this up.