Mattasmack

Well ... I just ran a simulation out to 400 Ms, and at the end the relative error in energy was 2x10-11, in linear momentum was 1.7x10-11, and in angular momentum was 5.8x10-11. Those are the values I have the program calculate to judge error. The momentum errors are a bit higher than I got running my simulation of the stock Kerbol system out to 3x109 s. But something horrible happens just after 101 Ms; my program spams messages about collisions between Jool and Minmus and thereafter it's forced to use a much smaller time step. It looks like Minmus falls into Jool, but I haven't rendered a movie from the data so I don't know exactly what happened yet. I'm about to start doing just that and go to bed. Incidentally, I get a collision between Mun and Kerbin at about 8 Ms, then several between Minmus and Jool between 51 and 58 Ms, and another between Minmus and Laythe at 57 Ms. (So running the simulation as long as I did doesn't really make sense anyway.) This is all done with the initial states of the bodies set using Keplerian orbital parameters exactly as they're stated (i.e., I don't try to make any sort of correction for bodies moving around their barycenter), and of course I could have an error there. I used the stock mean anomaly at epoch for each body, since that seems to be what the current version of Alternis uses (maybe? unless it's random?), except for Gilly and Ike where I used the Mt values you suggested in an earlier post.

Ah, I was just working on that. I wasn't 100% confident of the results, but it looked like the Jool system blew up pretty well in Alternis too. Including collisions between moons before they get ejected. Your comets and inclined orbits messed up my neat little arrangement of boxes for displaying the orbits, so I'll continue working on that while waiting for the next version. (Not that I'm complaining; this is fun!)

So ... the game reports true anomaly in degrees, but the other anomalies in radians?! Good grief. Do you happen to know what units the other angular parameters are in? Just from looking at the orbits in the game's map view it seems that inclination is in degrees, but I can't really tell about the argument of periapsis or longitude of ascending node. I suppose if it reports the LAN as 180 for some bodies (rather than wrapping it into the range 0 .. 2*pi) that's evidence that it's in degrees, but I don't really want to trust that. (Or, is there documentation of this stuff somewhere that I should know about?)

That shouldn't be too hard to set up. I just had a glance at your source code, and I see I can get the Kepler orbital parameters from PlanetShifter.cs. I didn't see any planetary masses or gravitational parameters, though. Are they in there and I should just look harder, or are they hiding somewhere else? I think you changed some bodies' radii and/or surface gravity so the masses shouldn't be the same as in the stock game. Once I find all the numbers, I should be able to put a video up of a simulation in about a day.

They are good comments, I think! Others have responded already, but I'd like to add another thought regarding your first two questions. There's another thread in this general discussion forum that has screenshots from the very first versions of the game. If you look at them, you'll see the parts the game originally had are very similar to the parts you start with in career mode (e.g. 1-Kerbal capsule, fuel tank, engine, solid rocket). Airplane parts were first developed by a modder member of the community and were only added to the stock game in a later version. Although airplane parts are widely used and appreciated by the community now, I think the developers still think of those basic rocket parts as the 'core' of the game, and my guess is that making them the starting parts in career mode was just the default option to them. The tech tree partially mirrors the development of the game, as well as a progression of more advanced parts. Regarding your questions about the usefulness of probes fairly early on in career mode (i.e. before solar panels, batteries, etc.) ... good questions! I don't think the tech tree was changed in this version except to add the new parts, so we're still looking at essentially the first publicly-released version. I expect (I hope) that it will get changed in future versions to iron out wrinkles like that. For now, as others have said, there are mods that change the tech tree.

Don't forget that you can move data around now, too. Others have mentioned going back and forth between the different biomes on the Mun and a lab at the Mun already. But you don't have to transmit the results from the lab. Instead, you can EVA to take the science out of the goo and/or materials containers and move it to your return capsule, then use the lab to reset the containers to take back to a different biome. The return capsule can store one copy of the science results from each biome and at the end take all the data back to Kerbin for recovery.

Err, the upper limit of a 32-bit floating point number is somewhere around 1038. He's quite a few orders of magnitude short of that. Perhaps you were thinking of the upper limit of a signed 32-bit integer (~2x109), although the velocity certainly isn't stored as an integer in m/s. The (not very close) correspondence between his speed and that limit is surely coincidence.

Thanks for the link to the article, it is indeed an interesting read. You're right that it being a multistep method rules it out for this application, I think. Since we can't know ahead of time what paths players will put vessels on, it is important to use a method that can adapt its time step to maintain stability and a specified error limit. (Such a method can also calculate orbits with high eccentricity much more efficiently than fixed time step methods.) The moderate-order RK method I've been looking at also has the property that an interpolating function for position can easily be calculated of the same order as the RK method itself. That's valuable for use in the game because it makes it much cheaper computationally to find locations like AP, PE, ascending and decending nodes, etc., and to find each vessel's location frame-by-frame without having to do integration steps each frame. (Which is the sort of consideration that usually doesn't come up for pure simulations.) Exactly. I did one quick simulation with Kerbol and Kerbin following Kepler orbits around their barycenter, and in that case an object placed at the L4 point hardly drifted away at all. (It still drifted slightly -- a few tens of meters over a few years -- probably because I didn't keep enough sig. figs when entering the orbital parameters for the two bodies.) But I did that simulation mostly for my peace of mind, to ensure that the reason the L-points weren't working wasn't that I had screwed something up in my code. Once the rest of the bodies in the Kerbol system are added in, that can't be done any more. If I do manage to implement these orbits I'd be perfectly happy to abstract away stationkeeping, at least at first. E.g., press a button to turn on 'stationkeeping', and it just moves the vessel back onto a Keplerian orbit. The costs could be abstracted as well, just remove fuel at a fixed rate (dependent on the orbit, the vessel's size, etc.) as long as stationkeeping is enabled.

It's a reasonable enough assumption. But, if you use 1 fuel unit = 1 liter, you end up with fuel densities that are very high and the fraction of tanks actually occupied by fuel is very low. If you assume instead that 1 fuel unit = 5 liters, you get fuel densities that correspond more closely to real-life rocket fuels and the volume of fuel in the fuel tanks is much more sensible. I would guess that the devs used 1 unit = 5 liters when setting up fuel properties and tanks, but since they've never said so explicitly (as far as I know, and I don't think the wiki is definitive) it's only my guess. I like the name 'fuel cubit' for the unit of fuel, which I saw in a thread some time back.

Not much progress to speak of, unfortunately. I started learning Unity and plug in development, but after seeing just how many objects are associated with KSP and how little documented they are, I moved this project down several slots on my to-do list. Plus real life has intervened for the past six weeks or so. My wife and I moved last month and my stuff just arrived from storage. The living room and my (eventual) office are full of boxes, and the computer I'd prefer to use for software development is busted. There isn't really any code to speak of to release. I still hope to go somewhere with this project eventually, but it isn't my top priority at this time. Using an inherently energy-conserving method isn't really important, especially since having the planetary bodies follow Keplerian orbits means the whole system doesn't conserve energy in the first place. Plus, I was envisioning using the Newtonian trajectories only at high enough altitudes above each planetary body that they would be used only where an orbit shouldn't be expected to be stable anyway. With a decent integration scheme and reasonable error limit, any numerical drift would be small compared to perturbation of the orbit by other bodies, and therefore not a problem. Incidentally, I went ahead and did an N-body simulation of the Kerbol system using this RK5(4) method just for fun, and over an error limit range of a few orders of magnitude the results were essentially the same for simulation lengths of 100 years. Over astronomical time periods an inherently energy-conserving method is probably important, but not over the length of a game. Unfortunately no. Having the planets and moons continue to follow Keplerian orbits means the balance of forces that make L-points and halo orbits exist is upset. Or at least, that's what I found in some simple tests back in September. I talked about them a bit more in the thread in the general discussion forum. It's something I'd like to explore further someday.

I do like this idea as a simple in-game (non-immersion-breaking) way to avoid all the complexities of Newtonian trajectories (or to stabilize an orbit that shouldn't really be stable) if the player wants to. You're right, I'm sure it would be exploitable, but it's not really a problem. Yeah, celestial bodies can just stay on the Keplerian rails they're on now. That's what I've been looking at so far. I'm ignoring gravitational interaction between the vessels themselves, too. In short, it's not an n-body simulation. That makes it possible to calculate each object's trajectory independently of all the others'. I was just playing around with that the other day, and I'm waiting for some figures to render so I can show it on Youtube. For a time span of about 100 years (Earth years, not Kerbin years -- 3x109 s) the planets' orbits are stable, but Jool loses two moons. Jool loses them so quickly, I think the only way to stabilize them would be to disable the gravitational interaction between some (or all) of Jool's moons. The other moons seem OK, although some of their orbits wobble a bit (especially Gilly). All this is orthogonal to the topic of this thread; it's just something I did for fun and because I had most of the code written already. Yeah, trying to implement it in a mod is my intention. But this thread has been worthwhile; the feedback has been helpful in refining what any scheme using Newtonian mechanics should (and should not) do, I've gotten some good ideas out of it, and I've gotten in contact with people who are also interested in making it happen. (Also, I spent some of today helping relatives carry water-damaged stuff out of their basement (they live in Boulder, Colorado, which just got a freakishly large amount of rainfall; many homes there were flooded), and I can't think well enough to program but I can still write forum posts!)

These are good questions. First, I anticipate putting the boundary between Keplerian and Newtonian trajectories higher, say around 5000 km for Kerbin. The idea is that the most commonly-used orbits (LKO or synchronous) would be below the transition altitude so that the situation you describe is not a common one. Second, it would be important to show a marker on the trajectory at the Kepler-Newtonian transition point. The player would need to see when he/she is in a situation where his/her vessel is in a guaranteed stable orbit, or not. I guess my point is that, as long as the player is informed when an orbit is guaranteed to be stable and when it is not, and as long as the region of Keplerian mechanics is reasonably large, I just don't think the drift of orbits outside of that region is a problem. Yes, any orbit that has any portion of it computed with Newtonian mechanics will drift, to a greater or lesser extent depending on the situation. The trajectories can be precomputed so that what is shown in map view is accurate (see below for more), so plotting a rendevous with another vessel using the information in map view would still work the same way it does now. No nasty surprises for the player (as in, the vessel not going where the map said it would). You are rather significantly overestimating the computational effort and storage required. By avoiding integrating low orbits and by using a moderate-order integration scheme, the time steps can be much larger. Using a 5th order Runge Kutta method, I found that time steps were between ~100s (for vessels just outside of where I would put the Newtonian-Keplerian transition above Kerbin) to millions and tens of millions of seconds for vessels in interplanetary space. Typically a few hundred to just over a thousand time steps are needed to compute a full orbit. These time steps are of course much larger than the time between frames, so intepolation can be used to accurately and quickly obtain a vessel's state at any point within a time step. Storing 1000 time steps with interpolation data requires about 200 kB. And (once again) it's not an n-body simulation -- the planetary bodies stay on their Keplerian trajectories, which also allows the time step used to integrate each vessel's trajectory to be independent of all the others'. I realize it's very long-winded, but the article on my website (link in the original post) has many of these details about the computational effort required, magnitude of numerical inaccuracy, etc.. I am not just spouting off an idea, I did some homework first to check the feasibility of as many aspects of the idea as I could think of. Your overall point is valid; the computational effort of integrating Newtonian trajectories will indeed put a cap on time warp. But I don't think physics warp gives any sort of useful yardstick -- its speed limitation is part-to-part physics, which is a whole 'nother kettle of fish. In my simulations, I found that I could compute 60,000 - 75,000 steps per second if I used precomputed interpolation functions for the planetary body locations (computing their locations from their Keplerian orbital elements was very costly, I think because of the several trig function calls required). This was for a thread running by itself on one core on my laptop, but with different levels of load on the other cores of the CPU (which accounts for the range 60k-75k). This isn't equivalent to running the simulations within KSP, but I believe it gives a rough estimate of what could be accomplished. In any case, taking the worst case of 100 s timesteps and assuming 50k steps calculated per second, the trajectories of fifty objects could be integrated at 100,000x time warp. And yes, any more than that would result in the time warp slowing down. I am sympathetic to your final point; realism for the sake of realism probably isn't a good enough reason to implement something like this. I undertook my little study because I had seen a number of conversations about why it couldn't be done, but the reasons were usually given without justification and I wanted to see what the technical hurdles really were. I'm interested in trying it in a mod because I'm curious to see what it looks like in-game -- I think it will be interesting.

That's partly why I also suggested not implementing Newtonian mechanics below a certain altitude from each body. That way, your station in low Kerbal orbit is still on a patched conic rail and will follow the exact same orbit forever or until you do something to it. (The other reasons are that the perturbations to the orbit are small enough for low orbits that there's not much point to having them, and that the low orbits require smaller time steps to compute.) See my previous paragraph. Patched conics can be retained for low (and medium) orbits without losing anything interesting, so there need not be any concern about stations in low orbit or communication satellites in Kerbin-synchonous orbit drifting away from where you left them. Numerical stability is not a problem. The trajectories have to be precomputed anyway to show them in map view. Simply store the trajectory (unless the player does something to cause the vessel to accelerate), and in time warp the vessel will follow that trajectory on a rail. The numerical integration should be done with an adaptive time step, where the time step is adjusted to keep the local error below a set limit anyway. Thus the player's use of time warp in the game would impact how much CPU time has to be devoted to computing the trajectories, but should have zero effect on their accuracy.

That is true ... my thinking was that leaving Kerbol stationary isn't just a periodic perturbation (as is Jupiter's influence on the Sun in your example) but is fundamentally nonphysical, so who knows what impact it has. But you certainly have a point. I'll try doing that when I have a chance. Running the simulation for longer is no problem, it goes very quickly. I haven't displayed anything in a rotational frame because when I looked at it I said 'bah, more trig!' and went and did something else instead. But I suppose I can just take the arctangent of the vector from the origin to the supposed L4 point to get the rotation angle; it's not really a 3D problem. I'll do that when I have a chance, hopefully today. That's one of the reasons I said the Newtonian mechanics should only kick in above a certain altitude from each body. The altitude can be set high enough that low-altitude orbits and other common orbits such as geosynchronous ones (at least for some bodies) will still be computed with patched conics and be perfectly repeatable. Ah, too bad. Well, asmi thinks it can be implemented in a mod, so we're going to give it a shot. If it goes anywhere, that will give an idea of just how difficult it is and whether the difference in behavior is enough to matter.

Yeah, I was kind of disappointed to learn that sun-synchronous orbits depended on the shape of the earth, not the influence of other bodies, because it meant any approach based on point masses wouldn't have them. In the back of my mind I have the idea of replacing the point mass of Kerbin with a small ring of masses (say, 4 - 8 of them) in its equatorial plane to see if that would have the same effect. It's not something I anticipate doing any time soon, though.

I'd like to follow up a little regarding L-points, since they came up several times in the thread. In my first look at Kerbin's L4 point, I simply looked at a system consisting of Kerbol (stationary, at the origin of my coordinate system) with Kerbin circling it in the orbit specified by the Kepler orbital elements given for it in the KSP wiki. When I placed an object where the L4 point ought to be and simulated its trajectory for the next 50 Ms (579 days, or 5.4 Kerbin years), its motion relative to the L4 point looked like this: In the figure, the origin is the supposed L4 point and is where the trajectory started. This is not plotted in a rotating reference frame, so the spiraling outwards is actually the object drifting downwards (towards Kerbol) and then ahead in its orbit. At the end of the simulation, it's some 64 Mm away from the starting point -- small compared to the orbital radius of ~ 13.6 Gm, but the object is definitely departing the vicinity. I played around with different starting velocities (but not really with different starting positions) and couldn't get any significant improvement over what's shown above. My explanation for this behavior was that Kerbol and Kerbin weren't actually moving as they should under Newtonian mechanics: Kerbol should not be stationary, instead it and Kerbin should both orbit their barycenter. The difference puts Kerbol about 41 km away from where it should be, and stationary instead of moving at about 3 cm/s through its little orbit. It's a small difference, but I think it is enough to upset the balance of forces that creates the L4 and L5 points in 'real life' (following Newtonian mechanics). Other possibilities include that I simply have a bug in my code, or that the spiral shown above is due to numerical drift. To test my explanation, I redid the simulations but with Kerbol following a small Kepler orbit around the origin, 180 degrees out of phase with Kerbin. This time, when I placed an object at the L4 point and ran the simulation for 50 Ms, I got this result: Once again the object is drifting away from the L-point, but at the end of the simulation it's only drifted by ~ 70 m! This still isn't numerical drift -- I ran multiple simulations with different error limits and got the same result each time. Instead, it's probably due to my not getting the two orbits of Kerbin and Kerbol exactly right to enough decimal places. In any case, I think this proves that the approach I described in my original post can't naturally produce L4 and L5 points as they are usually known. The motion of the planetary bodies in their Keplerian orbits just isn't correct for them to form. A full n-body simulation of the Kerbol system would probably be needed to get Lagrange points without resorting to gimmicks.

I'm hesitant to distribute it widely because it's raw and still a work-in-progress -- in most aspects, I tried things (like different integration schemes) until I found something good enough and then just went on to the next step. It's by no means optimal and it's not in a state that I wouldn't be embarrassed to show to the public. But if we are to work on a mod together I'll still be able to fix things up as necessary and improve it. In any case, it's also totally uncommented at the moment, which does not aid understanding. Let me comment it and then I'll send it to you.

Keeping up with real-time is easy, and velocity Verlet would be good enough. But for map view to still work, I need to quickly predict each object's trajectory into the future (and then store that trajectory so that the vessel can follow it). I also need to recalculate the predicted trajectory as quickly as possible so that the player can still see some prediction in map view while his/her vessel is accelerating. And the calculations have to keep up with 100,000x time warp! If any of these don't work, then while the concept might work for simulations, it's a non-starter for KSP the game. I'm not sure about symplectic integrators. I think I'll have to look at them at some point, although they're not needed for a first cut at the problem. But energy isn't conserved! My plan is to leave the planetary bodies on their current Keplerian trajectories, so a vessel getting a gravitational slingshot around a planet will gain energy without any other object losing it. Agreed!

Exactly. Since there are only 17 bodies in the Kerbol system, it's not unreasonable (and is simplest) to have each body influence each vessel all the time (within limitations -- see the original thread for more info, or this very long-winded article on my website for more on my no-man's-land concept for avoiding doing the calculations when in low orbits where they don't really matter). I have tried the simulations, and I can tell you the calculations are not that intensive. It is crucial to use at least a moderate-order integrator that allows long time steps to be taken. That way, for vessels that aren't under acceleration, a calculation only needs to be done every few tens of seconds (if in orbit around a planet) to every few millions of seconds (if in orbit around Kerbol in the outer solar system). The need for more calculations does grow with time warp, and they would need to be done continuously for a vessel that's accelerating. I have code for the trajectory calculation and interpolation that should be good enough for a proof-of-concept. (Though if it proves promising, higher-order integrators and schemes other than RK should be looked at, and approximations like what you suggest might prove to be necessary.) What I don't know is how to get it into a plugin for KSP, or if the necessary parts of KSP are even accessible to the modder.

I really want to do an n-body simulation of the Kerbol system, just to see what happens! I expect to see moons flying all around the system, it should be awesome. Well, conversations in this vein seem to gravitate to n-body simulations. If nothing else, it's an interesting question of what would happen (see above) as long as it hasn't been tried. But I explicitly, and specifically, started this thread with a scheme that is not n-body simulation. And that avoids the need for very high-order numerical methods and/or short timesteps by not switching to Newtonian mechanics until an object reaches a relatively high distance from all planetary bodies. (Though higher-order methods than the ones I looked at would still be beneficial, I assume.)

That's something I played around a bit with yesterday, actually. I divided each body's orbit around its parent into segments and precalculated fifth-order polynomials in each segment to approximate its location. That's not at all optimized, but it worked surprisingly well. The number of segments needed for maximum location error less than 1 m ranged from 11 (for moons with circular orbits) to 118 (for Eeloo, with its large and eccentric orbit). The total amount of data to be stored was just under 100k, and I got about a 3x speedup above the fastest implementation using sines and cosines. Yeah, just being able to display the Newtonian trajectories alongside the patched conics ones would be a benefit, I think. It answers the question, "so just how much difference does it make?" Thread created, let's see what happens. I'm in no hurry; I don't know anything about modding KSP so I'm going to try to educate myself a bit in the next couple of days, which will certainly keep me busy. I haven't written out the equations here on the forum because there are lots of them and I'm not eager to struggle with formatting them here to get them readable. I'd rather just point you to the paper I used for a reference, Shampine (1986). The Butcher tableau on pages 148-149 is what I used, and it covers both the time integration and producing enough information to generate interpolation functions within a time step. If you'd like more detail, I'd just as soon show you my code.

This thread stems from a thread I recently started in the general discussion forum. I believe that in terms of computational effort and numerical accuracy, it should be possible to calculate the trajectories of objects in KSP using Newtonian mechanics rather than Kepler's laws, and do so in a way that doesn't make things harder or more confusing for the average player. Naturally this is not something that the developers would tackle any time soon, and it was suggested that I should try implementing the idea in a mod first to see if it really can be done. So, here I am! Note that I am not talking about n-body simulations. I want to leave the planetary bodies alone, I just want vessels in space to be subject to gravity from multiple bodies at once. For that matter, as asmi suggested, I'd be happy for starters to just be able to display the Newtonian trajectories in map view. So, I have already the C++ code I wrote to do my little simulations to test the concept out, and that works reasonably well and is fast. It uses Dormand and Prince's RK5(4)7M scheme with an additional solution at the midpoint of the time step, per Shampine, which is used to calculate a 5th order interpolation function for location. I also added lookup tables for the planetary body locations that speeds the scheme up considerably (since calculating planetary body locations from Kepler orbital elements was the most costly part of the simulations). What I don't know anything about is modding KSP! I'd appreciate any pointers regarding how to access things like the curves shown in map view, if it is indeed possible at all. Or if someone is interested with helping program the plugin, I'm willing to share my code.

1: I don't think anyone here said they do, although I might have missed it. Who are you replying to here? 2: Good to know! 3: Yeah, being able to just specify the Keplerian orbital elements and then leave it alone unless and until you need to calculate a position (rather than integrating the trajectory) is a big advantage. But has anyone actually done a study of how many independent objects can be in space in KSP before it starts to lag? I would expect it to be in the mid- to high-hundreds rather than tens of thousands. Actually calculating a position from the orbital elements involves several sin() and cos() calls, and those get costly quickly. (In my own simulations, I found that calculating the planetary body locations from their orbital elements was by far the most costly part of the simulation.) I hadn't even considered trying to implement the Newtonian trajectories in a mod, I assumed that trajectories and the curves shown in map view weren't accessible to the modder. If they are, well, it would be very cool indeed to try this method out that way. For a first cut at it, I don't think there's any need to worry about parallelization at all, although if it proved successful and other optimizations had been done it would help improve performance. I don't know how much the GPU would help; these calculations must be done in double precision, and I was under the impression that most GPUs don't actually provide all that many double precision FLOPS. I'd be happy to provide the equations, but what level of detail or what sort of information are you looking for? The article on my website (linked from my original post) has links to the articles I used for the core parts of the simulation (the embedded Runge Kutta scheme and the interpolation scheme for it), and I can go into more detail on the other parts or give a more coherent overview of the whole thing if you'd like.

I don't know if a change like this would really increase the difficulty very much. I don't think it will (the biggest aid the player has -- being able to see where their trajectory will take them in map view -- will still work), but I admit I'm guessing. Well, I put an object where Kerbin's L4 point ought to be, and it didn't stay there. There are different possible explanations, including simply that I've made an error, either a bug in the code or in my initial placement of the object. I don't think it's a matter of numerical drift, because I can change the local error limit of the RK scheme by a few orders of magnitude and see no significant difference in the result. My theory is that the problem is that Kerbin's orbit is centered around Kerbol's center (which is stationary), rather than the center of mass of the Kerbin-Kerbol system. So the two bodies aren't quite where the ought to be for the forces to balance properly to form the L4 point. The difference is small, but the drift away from the L-point is also slow at first (as compared to the radius of Kerbin's orbit). Now that would be cool! That's something I've wished I could figure out before -- when and how to launch a rocket so that it can get multiple gravity assists on its way to another planet (or out of the solar system entirely).

I'm glad we agree that this isn't something to add to the game right now! As I said initially, I am not suggesting that any change from patched conics trajectories be made now; if I were, I would have started the thread in the suggestions subforum. Rather, I was inspired by earlier conversations on the topic to try Newtonian simulations in the KSP solar system myself and see what technical issues actually came up, and see if and how they could be mitigated or avoided. My purpose in starting this thread was to share what I learned and hear from others. And in that vein, I don't think it's particularly important that trajectory calculations and part-to-part physics calculations are in the same thread right now. They don't have to be. In fact, if mods like FAR run in separate threads as you say, then we already have a working example of some physics calculations being offloaded into a separate thread. As I said, the scheme I have been looking at is fast enough to calculate the trajectories of several vessels at 100,000x warp (on my not-very-fast laptop, but running in its own thread). The calculations needed at 1x warp are negligible. And while time-warping, when more trajectory calculations are needed, there are no part-to-part calculations to compete with. The case where the most trajectory calculations are needed is when the player's vessel is under acceleration and the player is in map view, so that the projected trajectory needs to be continuously recalculated so that it can be displayed to the player. Even in this case, calculating the vessel's current state from one frame to the next is trivial, so that need not hold up the game frame-to-frame. But if calculating the projected trajectory is put in its own thread, it will happily use up all the CPU cycles available to it, calculating the current trajectory out as far as possible before throwing it away to start over from newer data. That's the one case where the player wouldn't get feedback in map view as quickly as he or she does now. It should take only a fraction of a second to calculate the new predicted trajectory, but it wouldn't be fast enough to do each frame.