eggrobin

Allow me to shamelessly advertise my---somewhat unstable---mod, principia. You can get a WIP build by going to the IRC channel linked in the OP.

Status update: The new version, Borel, is out (you can get it on IRC, as previously; the same caveats apply). Rough changelog: ported to 1.0.x (that only took a couple of lines); custom navball settings, so that the navball can be fixed in the reference frame in which the trajectory is plotted; the IVA navball is unaffected; when using the custom navball, the prograde/retrograde vectors are now in the correct reference frame, consistent with what is shown is map view; the rest of the Frenet trihedron (the radial and normal vectors) are unaffected at the moment and will be fixed in another version; fixed a few bugs (the tetrydsbug, the melonbug, the thutmosebug); less memory-hungry; added a setting to clip histories; added a toolbar button to show/hide the UI; the UI now acknowledges the F2 key; other things that I forgot. Moreover, Norgg and armed_troop have made good progress on Linux 64-bit and Macintosh 32-bit builds respectively, so if you're on these platforms you can go on IRC and ask for a build or for build instructions. With Windows 32-bit, Linux 64-bit and Macintosh 32-bit, we should be covering most users (I don't think it's worth doing a Linux 32-bit build).

The answer is going to be terse, since I'm on vacation and on a phone. 2. The planet and the sun, or the moon and the planet, or the ship and some massive body, that's 2. The 1-body problem is hardly interesting, the body just moves in a straight line. No, it's called Principia. The rest of the thread title is a description. The simulation of the trajectories (let us not call it the orbit, that is confusing), even at high timewarp, is not all that CPU-intensive. The predictions are costly at the moment, but the use of other integration methods should improve performance by several orders of magnitude. You mean 3. The penultimate sentence does not parse. So, what you are proposing is ignoring far-away bodies, which has been suggested countless times. As I said a few posts ago, I am interested in approximations (what I currently do *is* an approximation after all), but I seek the best approximation I can have for a given computational cost. FMM-like approximations may end up being useful, but for now they are dwarfed by other things. See also the FAQ I made before going on vacation, https://github.com/mockingbirdnest/Principia/wiki/Installing%2C-reporting-bugs%2C-and-frequently-asked-questions I see yargnit has answered this too, albeit with some mild inaccuracies, see also that.

This is, of course, false. Even ignoring the race condition here, the intended output is n copies of "Hello, world." when one has n cores in this example. Race conditions do of course occur, and for all practical purposes this is a threading library written in pragmas (with high-level parallelization utilities on top of that). In particular, the usual issues of synchronization and locking exist (and these are not transparent at all). While this filled the lack of portable threads back in the days of C++98, such concerns are no longer relevant with C++11 and later, which has actual threading libraries that are fully part of the language. As for GPGPU, actual language extensions exist for that (you mentioned C++AMP), and they come, of course, with restrictions, because that's how GPUs are. You seem to be missing the main point however, which is that whatever speedup one might get from parallelization of either kind right now is dwarfed by a couple of orders of magnitude by what we're trying to get out of the maths (with things like integrating exactly the Keplerian part, or in a completely opposite direction trying multistep methods), and have to be made after a method is chosen (the computations we'll end up doing are probably very different from what we're doing now), to see if it can be made parallel in a way that improves performance (most of these calculations are very sequential) and doesn't break abstractions. See OP or previous page.

That post is messy, but it is a good idea to read it. For CPU threading I'd rather implement it myself using the C++11 threading libraries (we're using them already in some places) and make sure that I'm not introducing race conditions. Bear in mind that since C++11, C++ actually has portable threads. That parallelization by pragmas also seems to violate Bob Duff's Rule of Good Taste in Pragmas. It still requires to deeply change the code (and making things portable to non-AMP compilers is a little bit of work too), although some abstractions could survive, so it is nicer than rewriting everything in OpenCL. Note that for GPGPU, similar concerns apply as for regular threading (it's not obvious that there is much to be gained, since as soon as one gets out of the force computation things get sequential again). In addition, bear in mind that I really need to work with (at least) double-precision floating point, which seems to be a problem for GPGPU.

I'm not familiar with this at all, there are gigantic optimizations that I know how to do before that, so I'll stick to my beloved CPU for now Also, the main reason for the switch to C++ was my template-happiness (I love strong typing). This sort of idea actually exists, it's the fast multipole method. In the current state of things it would only yield a relatively small speedup compared to things like picking another splitting, or choosing a better integrator (more stages, method with a processor, method optimized for near-integrable systems, etc.). It would definitely be relevant if I were to model, e.g., asteroid belts. Regarding threading in principia, if it's possible it will be complicated, since the costly part that isn't essentially sequential is the force computation itself, but that's called often and the synchronization might be too costly. It is definitely something to consider, but not right now. Right now the way forward is being smarter with the mathematics. Hey, I like approximations... as long as you can show that they're best possible for a given computational cost

Status update: Serialization has been implemented, and rudimentary predictions have been added. The predictions are currently using the same integration method (McLachlan and Atela's 1992 optimal 5th order method), with the same splitting of the Hamiltonian (kinetic + potential energy), this is somewhat usable but unacceptably slow. I am currently implementing as many symplectic integrators as I can find in order to compare them, and I will also be comparing various splittings (as as nonsymplectic methods in use for computing ephemerides). I will probably write a post about these at some point (probably an advanced one, rather than an elementary introduction, this is quite a complicated topic). It seems that there is some interest in builds of Principia, no matter how unstable or slow they may be. If you want to try out the current version of Principia (Bolzano) for the Windows 32-bit version of KSP, go the IRC channel linked below and ask me for a build (my nickname there is egg, or sometimes something of the form egg|<status>|egg). CAVEAT: The current version is not stable, it can corrupt or otherwise destroy saves, it has been known to crash, and predictions are horrendously slow. #principia IRC channel on EsperNet.

Possibly, have you tried looking at the build output?

As stated in the first line of the instructions for building principia, you need VS 2013 (an Express will apparently do, since kikill managed to compile things with that, for 2013 you could also use Community nowadays). I'm pretty sure I'm animate, and that it should therefore be the developer himself. I will not be linking binaries from the fora until I'm confident that it will be stable enough not to flood me with annoying bug reports. In addition releasing too early, with a slower than ideal version, would foster the rampant misconceptions about this problem being unsolvable. If you really want to try it out (only on Windows with 32-bit KSP at the moment), you can follow closely the instructions I linked, and things should work (read the last few posts for some caveats). It may (and some builds have been known to) crash intempestively, corrupt your save, summon great old ones, etc.

You can't (you probably need VS2013 pro or ultimate to have it), but you don't need it, Microsoft.VisualStudio.Coverage.Analysis is used in the coverage analyser which is just an utility with which we check how well the code is covered by the unit tests. ksp_plugin_adapter.dll and principia.dll (from Release/GameData/Principia) are the DLLs you need (you should put them, unsurprisingly, in GameData/Principia in your KSP install). You should, of course, use the 32-bit version of KSP (principia is a 32-bit native DLL). By the way, no need to translate the build output, I'm French.

You're welcome! I should add something to the protobuf patch someday so that it builds things in the correct order, incorect build order is why it has to be built twice...

It's only a problem off-rails. I think I know how to fix the ~20 mm s-2 acceleration due to badly initialized things. Thrust during timewarp is unrelated to this (but won't be implemented soon, things like predictions are a bigger priority). Your errors seem to say that the protocompiler (which creates these .pb.h and .pb.cc files) didn't run. Did you follow the setup a while ago? It changed recently, protobuf is now a dependency, and you need to build it to have the protocompiler. Looking at the build output, rather than just the list of errors, will probably yield more information.

Yes (4 seconds apart, as shown by the MET). That is correct (although this only define one axis, so the other two are defined by making the orbit plane invariant in addition to the line through the bodies). Consider that this is the frame in which a free-return trajectory would look like a figure-eight. I I'm orbiting L4 from quite far away. Had I manœuvred more precisely, I could have come closer to L4 with a smaller velocity in the rotating frame, resulting in a tighter orbit. My trajectory stays somewhat close to L4, rather than drifting away. It might help to show the gravitational + centrifugal potential.

The dependencies are open-source Google libraries, which are portable, and we try to make our code portable too. It's been a ridiculously long time since I've made one of these, and I should have made one in December when I got intrinsic acceleration working... Retroactive Status Update: antedated 2014-12-13 Support for intrinsic acceleration has been added. Refactoring will be needed, but it works, as demonstrated by the following plane change manœuvre: Status Update: The refactoring of the physics bubble has been done (and some tests have been added), as well as some cleanup in the C# adapter (including some performance improvements, a lot of the performance issues occur on the C# side since the implementation is a bit careless there). More refactoring occurred (use of a not_null template for non-null pointers). The next step on the path towards playability is persistence: the state of the plugin must be persisted so that we remember the states of the planets, the histories of the vessel trajectories, etc. (currently loading a save or reverting will result in either a crash or a loss of consistency due to the planets having moved around). Persistence of our types will be achieved using protocol buffers, stored in config nodes: we don't want to use KSP's config format directly, since we have lots of highly structured data and operate far from KSP's API it would be inefficient and clumsy. We'll probably also use protobufs for caching when implementing trajectory predictions later on. Some work has already been done in that direction. Here are some more screenshots, showing a flight from Kerbin to the Kerbin-Mun L4 Lagrange point (the reference frame for each screenshot is indicated in the "Traces of various description" window).

It's either the cross product, or the dot product, depending what you put in it: vector wedge vector is bivector (cross on the coordinates), bivector wedge vector is trivector (dot). It's really an algebraic wrapper on operations you know, that keeps track of what kind of object you have (i.e. how they transform under coordinate changes). Keeping track of that also prevents you from doing meaningless operations (e.g., adding a pseudovector to a vector), much like dimensional analysis does. But I am talking about 3D geometry here. See this wikipedia article for a physical example, and this one for the formalism. Using left-handed reference frames is not an issue per se, the laws of physics are the same through the looking-glass (we're not dealing with weak interaction here), but using both handednesses is mad (and can be no good reason to do so, since the laws of physics work are same through the looking-glass). In order to safely deal with both handednesses, you need to distinguish vectors and bivectors, since they transform differently.

Thanks! Regarding Grassmann algebras, you may be more familiar with the terminology "pseudovector" or "axial vector" for bivector, "pseudoscalar" for trivector. See also [Tao 2012] in the bibliography. yeah, with a proper interpretation of the orbital parameters (pre-Pol, but this shouldn't matter), Scott showed the system was stable, see the OP (this question seems to come up fairly often, I need to make the OP more readable at some point). unstable low orbits are in the far future (I need to discuss that with ferram4, it's aerodynamics), I guess that update will have to come with basic stationkeeping. Yes, see also below, it's a completely different kind of problem. I took Lagrange points as an example since it's fairly easy to work out analytically (and people seem to get excited about those). The whole point of using the 2-body problem is that you don't integrate it, you solve it exactly (well, you have to solve Kepler's equation, but no numerical integration is involved). This is what KSP does. One could make bodies orbit barycentres rather than centres, by essentially rewriting KSP's Orbit class, but I'm not interested in doing that (it's a completely different exercise). This is why I have strongly-typed reference frames. Obtuse is probably an understatement. As discussed above, it would not be an integrator, and stationkeeping will not be necessary for relatively low orbits (or anything where one massive body dominates) for a while. I wonder what the point of a mod that doesn't affect gameplay at all actually is ... A couple of things should be said here: - This mod is almost entirely in C++ (not C++/CLI, the interfacing is done via P/Invoke). KSP is not, virtually no other mod is. I'd say that makes this mod one of the hardest to integrate in their codebase. - I have no reason to want this to become stock: The best I could hope for is that I could somehow disable the stock implementation and replace it with my own to keep modding. See ferram4's concerns about improved aerodynamics in stock. Note: I will not be actively developing this mod until mid-February because of exams (the astute reader may have noticed that this happens every 6 months).

As discussed several times in the thread (although apparently not in the OP; I need to restructure that OP a bit anyway, the pile of status updates is getting unwieldy), the movement of the planets *has* to be redone in order for physics not to break down: if bodies orbit centres of other bodies, rather the barycentre, you're going to have a hard time finding L4 and L5 (just compute the potential in the rotating frame for that, its gradient only vanishes in 3 points rather than 5). The additional cost is not very large: B(B-1)/2 force computations, vs. the BV required to integrate the vessels; remember that the number of bodies is small and fixed.

See the OP,

It's all on the repository, under documentation. It should be compiled with XeLaTeX. It uses a package of mine which (rather unsuccessfully) tries to make the syntax semantically saner, and also autosizes brackets ignoring super- and subscripts. It turns out that I have twice as much LaTeX as I have C#... (GitHub stats)

Regarding useWorldSpace: Will be dealt with in #17. A note regarding smoke: as mentioned above, the HotRockets models predate my neat physical features (buoyancy, drag etc.), and in particular they use damping (which leads to smoke awkwardly accumulating some distance away). Once I make damping removable, it would be preferable to remove it from your smoke effects, and replace it with adequately chosen buoyancy/drag etc. (your cfgs are not on GitHub, so I can't send you a fix easily). Another remark on smoke: from what I saw in the cfgs (I only quickly glanced at them, this may be incorrect), you seem to use grow (which results in exponential growth) with clamping. Clamped exponentials may not be the nicest-looking smoke shape we can do, linGrow (linear growth) would probably yield something more realistic. Regarding that which you call underexpansion, which I'll call overexpansion just to confuse matters further: at the moment you can make any combination of exponential, logarithmic, and linear growth (the combination is by adding the derivatives, which yields strange functions when you use both grow and logGrow, finding out which is left as an exercise to the reader and Mathematica). Something has to be added to allow for wobbly elliptic arcs in the jet boundary (in addition to the effects for the disks/diamonds themselves), but what should the long-term behaviour be? Exponential decay to zero? Exponential decay to a nonzero asymptote (that would have to be a new kind of 'grow')? Constant width of the flow, just fading?

I'll see what I can do, hopefully we can make that configurable on the SmokeScreen side of things, otherwise it shouldn't be too hard to make a decent enough flame using HotRocket assets (I did that when testing SmokeScreen after all). I've started trying this out by the way, the effects are indeed pretty! Looking at photographs, I now remember that I also wanted to see what I could do as far as shock diamonds are concerned...

It can be done, but the issues is speed: we can't have particles flying off at 2 km/s (you'd need a lot of particles). This may be useful for slow turbopump exhaut however. In order to do that, set Simulate World Space in Unity on your flame (in other words, make your flame as you would make smoke). The following illustrates the kind of flame I'm talking about: Note that for this you'd also want to set some buoyancy, etc.

Vulcain 2: This says that the bell is 2.32 m high (it also says there are 288 tiny cooling tubes in the upper part of the bell, but that's because it's from an incident report where that was relevant). HM-7B: This says the bell is 0.99 m in diameter, and that the whole engine is 2.01 m high.

More information on Viking engines bells (Vikas are Indian clones of Viking). Note that in these drawings, only the bell is accurately represented (compare with photographs), but this should help with the dimensions.

Absolutely. The name isn't a very good criterion though, since the naming convention at the time seems to have been "let's call everything Viking".