[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

[Bedi]

You can always start with negative int:cool:

[eggrobin]

Will this mod allow for "Interplanetary Transport Network" trajectories / weak stability boundary /low energy transfers

Yes.

and if so, is that a result of a basic N-body model

Yes. In a way, you could see the crazy Mun-Kerbin transfer shown in the OP as such a trajectory.

Ok, it's been a long time since I've done a

Status update:

I now have a collaborator on Principia, https://github.com/pleroy (my father). This means the code gets reviewed and that development is faster.

We have decided to completely switch to C++/CLI due to better test tools and useful language features. Most of the code will actually be written in standard C++, with the implementation inlined in header files, so that they are seen by the eventual C++/CLI managed assembly (If we were to use C++/CLI everywhere, we would need managed boundaries between the assemblies, which is quite inconvenient).

As an added advantage, using standard C++ enables putting performance-critical parts into a native assembly if needed at a later time, without requiring a significant rework of the code.

We have started switching to gmock, gtest and glog for mocking, testing and logging. These tools are more convenient and powerful than the Visual Studio testing framework and are open source, so that users of Visual Studio Express (which does not support Microsoft's testing framework) will be able to build and run tests if they want to.

Here is the first test to be converted to gtest: https://github.com/mockingbirdnest/Principia/blob/master/geometry/sign_test.cpp.

Edited May 15, 2014 by eggrobin
Copy/paste editing sentences will be no grammar.

[dfrancis]

May I suggest a simplication?

From a sufficient distance planets and their moons (such as Jools) might be represented as a point mass of their total.

The location of the center of mass would be dependent on the position of the moons at the time.

This would reduce the number of Ns.

If the planets and moons remain on rails, the gravity they exert on each other does not need to be calculated.

The gravity exerted by ship parts is probably too small to need calculating. Would the gravity exerted by comets also be calculated?

Is there a plan to select the detail / accuracy of the calculations to reduce processor load?

[dfrancis]

Have you looked at a variable step integrator such as a predictor corrector?

Edited May 21, 2014 by dfrancis
Silly question

[eggrobin]

May I suggest a simplication?

From a sufficient distance planets and their moons (such as Jools) might be represented as a point mass of their total.

The location of the center of mass would be dependent on the position of the moons at the time.

This would reduce the number of Ns.

So, you're talking about a rudimentary version of the multipole method.

It has been discussed before. For asteroids it may be worth it (though asteroids can't really be approximated by point masses either, see the bottom of post 226), for moons and planets only it's not necessary. I might consider it if I decide to make asteroids massive.

If the planets and moons remain on rails, the gravity they exert on each other does not need to be calculated.

It's equally costly to keep the planets on rails for the number of planets we have, and it breaks things down completely since they orbit the centre of the primary rather than a barycentre. If I wanted to keep them on rails I'd have to make my own rails anyway.

The gravity exerted by ship parts is probably too small to need calculating. Would the gravity exerted by comets also be calculated?

Indeed, I intend to neglect gravitational field of vessels. There are no comets in stock KSP, those in Alternis Kerbol are celestial bodies (instances of CelestialBody), so they're like moons. Asteroids will be treated like vessels initially.

Is there a plan to select the detail / accuracy of the calculations to reduce processor load?

I'll have to write a few integrators to see which one works best, it should not be too hard to make settings for that sort of thing.

Have you looked at a variable step integrator such as a predictor corrector?

Variable steps break symplecticity, see [Chambers 1999], quoted in the OP (see the rest of the introduction to his paper, linked in the OP, for more details).

[Mipe]

Indeed, I intend to neglect gravitational field of vessels. There are no comets in stock KSP, those in Alternis Kerbol are celestial bodies (instances of CelestialBody), so they're like moons. Asteroids will be treated like vessels initially.

You, sir, appear to be underestimating the KSP players. The "FPS killer" ship category easily rivals asteroids in mass.

Imagine if such a ship and an asteroid were to meet... A mere flyby could alter the asteroid's trajectory. And the opposite would be true: when planning interplanetary missions, one'd have to watch out for asteroids, especially the more massive ones. Nothing that a brief burst of RCS can't fix, though - timely route correction can easily restore the trajectory.

I'd hate to be that guy who does his realtime missions afk, though...

[eggrobin]

You, sir, appear to be underestimating the KSP players. The "FPS killer" ship category easily rivals asteroids in mass.

Imagine if such a ship and an asteroid were to meet... A mere flyby could alter the asteroid's trajectory. And the opposite would be true: when planning interplanetary missions, one'd have to watch out for asteroids, especially the more massive ones. Nothing that a brief burst of RCS can't fix, though - timely route correction can easily restore the trajectory.

I'd hate to be that guy who does his realtime missions afk, though...

If I implement the gravitational field of asteroids (which is mostly hard problem at short distances, at long distances a point mass is decent, though FMM might be needed to accelerate things), it should be possible to take vessels into account as well.

[AndreyATGB]

Even a vessel the mass of a class E asteroid (1500t) is nothing compared to even Gilly which comes in at 1.2*10^17kg. Gilly barely has a gravitational field, a vessel the mass of an asteroid would need to be extremely far away from any body to affect anything else.

[eggrobin]

Even a vessel the mass of a class E asteroid (1500t) is nothing compared to even Gilly which comes in at 1.2*10^17kg. Gilly barely has a gravitational field, a vessel the mass of an asteroid would need to be extremely far away from any body to affect anything else.

Yeah, KSP asteroids are tiny and can probably be ignored. Gilly shouldn't be considered a spheroid though as far as field is concerned, it's really a large asteroid. That's the sort of body for which the more complex approaches linked by Scott would be appropriate.

[Aghanim]

I have another questions for this mod:

1. Does on rail warp still works here? Or now every vessel is loaded?

2. Because this mod is essentially a physics overhaul mod, is it possible to offload the calculations to OpenCL and do it on a graphics card or two? Doing vector FP64 calculations is faster in graphics card

Edited May 23, 2014 by Aghanim

[phoenix_ca]

I have another questions for this mod:

1. Does on rail warp still works here? Or now every vessel is loaded?

2. Because this mod is essentially a physics overhaul mod, is it possible to offload the calculations to OpenCL and do it on a graphics card or two? Doing vector FP64 calculations is faster in graphics card

1. I would think the whole point is that it could be done on rails. If it couldn't...there would be little point in still playing KSP.

2. I'm not sure you understand exactly what they're trying to do here. The calculations that determine the orbital properties of a vessel in KSP, and the physics engine that deals with how the ship behaves relative to itself and all its parts, are different things. As for actually sending calculations to a GPU, I'd instead ask if it's worth the time you'd have to spend on developing that. The problems associated with trying to offload calculations to a discrete GPU, and the tiny, tiny number of people who actually have multiple discrete GPUs make it, typically, a worthless endeavour.

[eggrobin]

I have another questions for this mod:

1. Does on rail warp still works here?

Yes. It's actually the part that has already been solved in the C# prototype, cf. the OP.

Also, as mentioned by phoenix_ca, it would be quite pointless otherwise...

2. Because this mod is essentially a physics overhaul mod, is it possible to offload the calculations to OpenCL and do it on a graphics card or two? Doing vector FP64 calculations is faster in graphics card

Discussed previously. GPGPU is probably not needed. If needed I might use native assemblies for the performance critical bits (which comes at a cost in portability, I'll need an assembly for Windows and one for each flavour of Unix), that should be enough. GPGPU would be even messier as far as portability is concerned, as described by phoenix_ca above.

Edited May 23, 2014 by eggrobin

[Dominiquini]

Firstly, congratulations for the initiative!

I do not know exactly what state is the development , but I would find it cool if this project were divided and resulted in several mods:

1) N-Body solar system: The orbits of celestial bodies would be adjusted to operate stably in this more realistic universe ( planets could be preset and placed " on-rails " inside the game, but I do not know if it is feasible if you need to change the way the game controls the motion of planets ).

2) N-Body vessels: The calculation of the gravitational forces on the ships ( and perhaps asteroids ) would be changed to simulate a realistic universe , which I believe is the main focus of your project.

3) StationKeeping: Mechanism to maintain the orbit of the spacecraft , which will become more unstable in this "new universe". It would be nice if this were done with a new part that could be attached to a ship with the control module and configured by the user (altitude , inclination and direction that should be kept; amounts of fuel and energy reserved for it, etc... ), acting as an autopilot that works "on-rails" or "off-rails" , and even when the ship is not loaded.

4) Timewarp thrust: Allow apply some acceleration on the ship while in timewarp. Also keep rotating the ship in this case...

Of course this makes much more sense if these features can be independent of each other!

Excuse me for my bad english...

[Phi Function]

Do I assume correctly that you will not support Linux, since you are programming in C++/CLI?

[eggrobin]

Firstly, congratulations for the initiative!

Thanks!

I do not know exactly what state is the development ,

See the OP, or the list of commits for something more detailed.

but I would find it cool if this project were divided and resulted in several mods:

1) N-Body solar system: The orbits of celestial bodies would be adjusted to operate stably in this more realistic universe ( planets could be preset and placed " on-rails " inside the game, but I do not know if it is feasible if you need to change the way the game controls the motion of planets ).

I'm not sure what you mean by that. Somehow tweaked Keplerian orbits? Integration?

2) N-Body vessels: The calculation of the gravitational forces on the ships ( and perhaps asteroids ) would be changed to simulate a realistic universe , which I believe is the main focus of your project.

Integrating the movement of the planets alone makes little sense though, so 1 & 2 should come together.

3) StationKeeping: Mechanism to maintain the orbit of the spacecraft , which will become more unstable in this "new universe". It would be nice if this were done with a new part that could be attached to a ship with the control module and configured by the user (altitude , inclination and direction that should be kept; amounts of fuel and energy reserved for it, etc... ), acting as an autopilot that works "on-rails" or "off-rails" , and even when the ship is not loaded.

Planned (see the OP), and extensively discussed (search the thread for "stationkeeping").

Mostly required for 1+2 to be playable with more than one ship at a time. Requires 1+2 of course, you need to know what gravitational field you're playing in.

4) Timewarp thrust: Allow apply some acceleration on the ship while in timewarp. Also keep rotating the ship in this case...

Planned, required for 3.

Of course this makes much more sense if these features can be independent of each other!

But they're not. If you find a way to split them (once they're implemented that is), feel free to fork the GitHub repository though!

[eggrobin]

Do I assume correctly that you will not support Linux, since you are programming in C++/CLI?

C++/CLI gets compiled to CIL, so that will support Linux (or any Unix that KSP runs on) just as well as an assembly written in C# (I'm not building a mixed-mode assembly since Unity doesn't support that anyway).

Unix compatibility is really the only reason not to use native assemblies (and Platform Invocation Services) from the beginning.

As mentioned in the last status update, most of the code will be standard C++ anyway, so I still have the possibility of putting some things in a native assembly later on (in which case I guess Unix users will have to build their own assemblies). If I did that I would probably keep a CIL-only version though.

Edited May 24, 2014 by eggrobin
grammars

[Phi Function]

C++/CLI gets compiled to CIL, so that will support Linux (or any Unix that KSP runs on) just as well as an assembly written in C# (I'm not building a mixed-mode assembly since Unity doesn't support that anyway).

Unix compatibility is really the only reason not to use native assemblies (and Platform Invocation Services) from the beginning.

As mentioned in the last status update, most of the code will be standard C++ anyway, so I still have the possibility of putting some things in a native assembly later on (in which case I guess Unix users will have to build their own assemblies). If I do that I would probably keep a CIL-only version though.

Great.

And thank you for this explaination. I never got into .NET programming.

[QuixoticKoala]

So discovering this may have put me out of a project I was going to do this summer. I was planning on modding the stock physics to replace the patched conics approximation currently used for determining the orbital paths of spacecraft with a matched asymptotics approximation, but you seem to have beaten me to the physics improvements (as I assume you are completely replacing the patched conics with N-body movement). That said, I'm not familiar enough with the KSP code to know exactly what you are changing, so I'm uncertain if the approximation I am proposing would still be useful as a mod. Still, if you could point me to any specifics about the exact code KSP uses for it's modeling, I would be very appreciative (I know it uses patched conics for the approximations and the planets are on rails, but not much beyond that).

[eggrobin]

I assume you are completely replacing the patched conics with N-body movement

I am integrating the equations of motion, see the title and the OP.

That said, I'm not familiar enough with the KSP code to know exactly what you are changing, so I'm uncertain if the approximation I am proposing would still be useful as a mod. Still, if you could point me to any specifics about the exact code KSP uses for it's modeling, I would be very appreciative (I know it uses patched conics for the approximations and the planets are on rails, but not much beyond that).

I'm pretty much just giving the game a new conic at every frame so it keeps doing its thing it blissful ignorance of its pointlessness, since I'll overwrite it all in the next frame.

I encourage you to try your solution, it's fun (and what I'm doing will take a while anyway).

You could try to look at HoneyFox's code too, or to ask any questions you may have on #kspmodders.

[Chase]

I am quite looking forward to a finished version of this. It will make KSP even funner.

[eggrobin]

Development is ongoing, but it's been a while since I made a

Status Update:

The integrator (still a 5th order SPRK, same as in the C# prototype, the Saha & Tremaine stuff isn't here yet) has been implemented, tested and benchmarked (using a Windows port of google/benchmark) in C++, as well as the first level of abstraction above it, principia::physics::NBodySystem (header, body, test, header for test data, test data, test of test data (which is also a nice example of the use of principia::quantities and principia::geometry, benchmark (using the test data)).

A significant change of plans has occured: As Unity uses the .NET Framework v2.0, it is not possible to use plugins compiled for the Framework v4.5. This means C++/CLI projects need to be compiled using the platform toolset v90 (from VS2008), rather than VS2013's v120. Of course v90 does not support C++11 nor C++14, so it is not an option for this code that strongly depends on C++11 features.

As a result, we will keep using the C++11 codebase, compiling it to a native DLL, and using P/Invoke to call it from a C# adapter. The C# adapter will perform no calculations, only transmit data from KSP to the native plugin and apply the changes/render the trajectories returned by the plugin. A simple test P/Invoke plugin can be seen on the repository (header, body, C# adapter) and works in KSP.

This means there will be separate x86 and AMD64 builds for each target operating system (Microsoft Windows and 57 varieties of Unix), possibly more if we decide to do specific optimisations for Intel chips (though ICC is not cheap).

Moreover, this will allow a switch to clang in the near future, so that we can have saner error messages and better compliance with the standard.

Native calculations should also be at least 30% faster than CLR ones.

Edited June 28, 2014 by eggrobin

[diomedea]

...

A significant change of plans has occured: As Unity uses the .NET Framework v2.0, it is not possible to use plugins compiled for the Framework v4.5.

...

Must say I am not an expert, but the above left me wondering why then all KSP plugins can work if compiled against a .NET Framework 3.5. So made a bit of research to find that:

- Unity does not use (directly) .NET Framework, but Mono. Mono is compliant with .NET Framework, in particular:

. Mono 2.0 is in par with .NET 2.0

. Mono 2.8 is in par with .NET 4.0

- The above leaves doubts about what specific version of Mono Unity is based on. Found here that Unity 4.3.3. (version used by KSP 0.23.5) uses a custom version of Mono (2.6.5.) mainly compliant with .NET 3.5

Hope the above may be of help. Can't say if all the functions you need are covered by Mono 2.6.5, but in case those were, you should be fine compiling for .NET 3.5; otherwise, you are right to use .NET 2.0

[eggrobin]

Must say I am not an expert, but the above left me wondering why then all KSP plugins can work if compiled against a .NET Framework 3.5. So made a bit of research to find that:

- Unity does not use (directly) .NET Framework, but Mono. Mono is compliant with .NET Framework, in particular:

. Mono 2.0 is in par with .NET 2.0

. Mono 2.8 is in par with .NET 4.0

- The above leaves doubts about what specific version of Mono Unity is based on. Found here that Unity 4.3.3. (version used by KSP 0.23.5) uses a custom version of Mono (2.6.5.) mainly compliant with .NET 3.5

Hope the above may be of help. Can't say if all the functions you need are covered by Mono 2.6.5, but in case those were, you should be fine compiling for .NET 3.5; otherwise, you are right to use .NET 2.0

The same consideration apply for both 2.0 and 3.5, you can't compile C++11 for it. It may well be that Unity is 3.5 and that its assembly incorrectly states that it uses the 2.0 runtime.

The C# bit shouldn't really need much of .NET anyway, all the fancy stuff will come from the stardard C++ libraries (for the moment Microsoft's, LLVM's libc++ whenever that gets ported to Windows).

[Garek]

This means there will be separate x86 and AMD64 builds for each target operating system (Microsoft Windows and 57 varieties of Unix), possibly more if we decide to do specific optimisations for Intel chips (though ICC is not cheap).

(Emphasis mine)

You actually want to do ~116 builds? I mean, automation helps, but the sheer amount of binaries would be...impressive. I use manjaro and personally would be okay with building myself from a Makefile (which would propably be the same at least for everyone using the gcc toolset).

[mic_e]

I must say I think you're overdoing the performance thing. Using an entirely different, even non-CLI language with platform-specific binaries, with all the trouble of interfacing it correctly and testing the release on every supported platform for every release, is a huge sacrifice just for 30%... I don't like C# either, and write all my performance-critical code in c++1y, but for KSP modding I'd just stick to C#...

Writing everything in C#, and then, after everything is stable and tested, putting a few performance-critical loops (< 100 lines of code) into a native dll, with a fallback to the original C# code if the native dll fails/is not available would have seemed like a far more reasonable approach to me.

How come your figures for '57 varieties of UNIX'? As far as I see it, it comes down to win32, win64, osx (does 32 even exist?), linux32 (barely anybody uses that anymore), linux64. I _think_ linux binaries even work on most BSDs these days.

What about the GNU standard library/compiler? It has been ported to Windows in the form of mingw32/mingw64, works pretty well, and _should_ be 1:1 interchangable with LLVM (just replace 'g++' with 'clang++' in the Makefile). In my experience, gcc binaries even are a little bit faster than clang's (and a lot faster than Microsoft's).

(peeks at the github) wow, that's a lot of commits; congratulations. You really _are_ putting a _lot_ of effort into this... (bows in awe)

Edited June 27, 2014 by mic_e