Mattasmack

Yes, at least in the simplest application you would just calculate the position of every planetary body and its associated gravitational force on a vessel at each time step. But they could be cut down if more performance is needed. For example, if the distance from a planet is above some limit, don't bother looking at its moons, or if the distance from Kerbol is large enough, don't bother calculating the locations of the inner planets. (Note that finding the location of a body from it's Kepler orbital elements is more costly than calculating the gravitational force once you have the location. So the significant speed-up comes from avoiding calculating the body's location in the first place.) The trajectories of all objects can be precalculated (the storage requirements are not too bad) so that they can be displayed in map view without any extra load on the CPU. So although the trajectories would be more complex, an object would still go exactly where the path in map view says it will. (It would be an interesting gameplay mechanic to show patched conics in the map view but calculate the trajectories differently, perhaps justified by the Kerbals not having good computers, but I think it would mostly just be frustrating to the player.) It would probably not be possible to continually update the full length of a trajectory while the vessel is accelerating, but it should take much less than a second to calculate out the full trajectory after acceleration ceases in most cases.

Yeah, that's essentially it. I do agree that the danger in making any change for the sake of realism is that it makes the game less approachable. But I think this hybrid system in which Keplerian orbits are retained inside a small SOI (which would still be shown in map view when crossing its boundary) mitigates it almost entirely. For example, I would envision the SOI for Kerbin having a limit somewhere in the range 4000 - 7000 km. That's high enough that vessels in low Kerbin orbit and even synchronous orbit would be inside the SOI and so would be perfectly stable. And the trajectories for vessels going through no-man's-land would still be displayed in map view, so although the paths would be more complex, they would still be predictable -- the player will always know where his or her vessel will end up. On floats vs. doubles: I don't know what is used in KSP currently. I think there might be a limitation in Unity so that part-to-part calculations are done with floats. (Which kind of makes sense, if they're using an engine meant to be useable on GPUs too, since most of their computing power is single-precision.) I assume (I hope!) they use doubles for all trajectories already. I only used doubles in my own simulations. On n-body physics: That's an important point, and something I perhaps should have emphasized more. I have not looked at n-body simulations at all; I just looked at letting vessels be influenced by gravity from multiple bodies at once. But the vessels don't influence the motion of the planetary bodies (thus breaking Newton's third law, but the ratio of masses between vessel and planet is so large it doesn't matter), and the vessels don't influence each other gravitationally. That means each vessel's trajectory can still be calculated completely independently of the others. On your last point: my notion of keeping a small SOI around each body in which Kepler's laws still apply is meant to mitigate that problem (and see my earlier comments in this post). Although, when I did some longer-term simulations of a vessel in LKO, I found that the influence of Mun was limited -- the orbit changed shape, but at least over a moderate amount of time the vessel wasn't pushed continually lower or higher such that it would eventually be lost. The question of whether making a change like this would be worth the trouble is, I think, the key one. I believe it is possible within the framework of KSP without hurting the gameplay. But is there a big enough benefit? I don't know the question could be answered without trying it in the game (which none of us are in a position to do), or at least putting some trajectories calculated using both methods in side-by-side comparisons (which I haven't yet done).

I won't respond to all you wrote (since, as you said, you hadn't fully read the post before responding), but I do want to comment on your statement that because the physics calculations in KSP are so costly, something else couldn't be added to the game. The part-to-part physics calculations certainly are costly; on my laptop the game is pretty much always chugging and using all the resources it can, either due to rendering or the physics calculations depending on the situation. But if what you say is the true state of affairs, that nothing else can be added because what is already there is so costly, it's a pretty lousy state of affairs. Either the developers really do need to drop everything else and do optimization (as posters occasionally complain about on the forum), or else expansion of the game is done. But I think your statement is incorrect, as evidenced by the popularity of mods that do add a moderate amount of additional calculation to the game (FAR, ISA Mapsat, MechJeb, etc.). Welcome! 1. Yeah, I thought of trying even higher order schemes -- I know Fehlberg published RK schemes up to 8th order back in the 60's, and I believe Dormand and Prince have an embedded 8th order scheme as well -- but after the 5th order scheme programmer fatigue set in! If I were actually implementing this approach those schemes, and ODEPACK, are things I would definitely look at. For the present, I just wanted to find out if the approach I had in mind would work or not, and the 5th order scheme I used was good enough I think. 2. Oh yes, there are certainly bugs! And that might be why the L-points didn't behave as expected. But I know that, by leaving the planets and moons in their Keplerian orbits, they are not moving as they "should" (i.e., Kerbin and Kerbol should be mutually orbiting their barycenter, but in KSP Kerbol is stationary), and I know that that also upsets the balance of forces that create the L-points to some extent. This is something I might look at more if I have time. I do think the notion of energy conservation is a red herring though. In the approach I've described here, with planets moving on fixed trajectories, the total energy in the system is not conserved! A vessel can take a gravitational slingshot around a planet and gain energy, and the planet doesn't lose any. Even in a true n-body simulation of the whole solar system, the difference in mass between Kerbol and the planets and spacecraft is so great that I think conserving energy of the system would be very difficult, to no significant gain that I can see.

That's a fair question! I'm having trouble putting an answer in words, so please excuse my rambling. Ignoring things like relativity, the Newtonian trajectory for a vessel is the correct one. Patched conics is an approximation. The patched conics trajectory is not dramatically wrong, but it is simplified. With Newtonian trajectories, basic things like the amount of time or delta-V to get from one place to another would still be about the same, but the path would be more complex. With Newtonian trajectories, a vessel in a high orbit around a planet has its path perturbed by the planet's moons or other bodies. It does not come back to the same place it started from after one orbit. Depending on the circumstances, over time the plane of the vessel's orbit could be changed or it might be pulled up or down into a different orbit or even out of orbit entirely. (Contrast with the current situation, where a vessel in an orbit will follow the same orbit forever unless it enters the SOI of another body or the player does something to change it.) With Keplerian trajectories, if you launch a vessel from low Kerbin orbit to Mun, unless you get an encounter with Mun (that is, the vessel enters Mun's SOI), Mun has no influence on the trajectory whatsoever. With Newtonian trajectories, Mun always exerts some pull on the vessel, which gets stronger and more significant as the vessel approaches Mun. The basic features of a transfer orbit between the two bodies is the same in either case, but two trajectories would differ in the details, especially for trajectories that would skirt the edge of Mun's SOI. I'll have to see if I can make some plots of similar trajectories in KSP and using Newtonian mechanics in the next day or two. Thanks! Right, whenever something happens to a vessel that imparts any acceleration (a collision, a rocket or RCS thruster firing, docking/undocking, a decoupler firing, etc.), its old precalculated trajectory is no longer valid and has to be thrown out. If a rocket is firing, that means the predicted trajectory is changing every single frame, so in the map view there would have to be some tradeoff between how often an old trajectory is thrown out and how far out the projected trajectory is shown. But I believe in most games, most objects in space will be debris (whose trajectories will never change on their own) or vessels in low circular orbits (mapping satellites, space stations, etc.). So the precalculated trajectories will not have to be thrown out very often, except for the case of interplanetary vessels that the player is actively controlling. Yeah, floats are totally inadequate for this sort of simulation and I didn't even consider trying them. Doubles have roughly 16 decimal digits of precision, which is good enough to give sub-millimeter resolution even out around Eeloo (assuming Kerbol is at the origin). I believe floats have around 7 digits of precision. And of course, these calculations are applied at the level of a whole vessel and give the trajectory of its center of mass. When focused on a vessel the interactions between individual parts would still be done with the origin defined as the vessel's center of mass, which I believe is how it's done now. Thanks!

I've seen a number of conversations here in the forums about patched conics in KSP and whether or how more realistic motion of spacecraft could be calculated using Newton's laws of motion. The threads have contained a lot of speculation about why a Newtonian approach might not work: too much numerical error or drift, high timewarp wouldn't be possible, showing trajectories in map view wouldn't be possible, etc. But I generally didn't see a lot of data to support anyone's conclusions, and I did my share of speculation too. I thought it would be an interesting exercise to generate some data by simulating trajectories of vessels in the KSP solar system using Newton's laws of motion and universal law of gravitation, and seeing what problems come up and whether they can be overcome. I haven't (yet) looked at n-body simulations of the KSP solar system -- I left the moons and planets in their current Keplerian trajectories and just simulated the motion of spacecraft around them. In short, I believe trajectories based on Newtonian mechanics can be used in KSP. This isn't a suggestion to make the change in KSP; the patched conics approach is good enough (for now at least), and if anything is going to be changed with the physics of the game I think it's PhysX that's the biggest problem right now. My goal here is to just inform discussions on the topic. I put a much more long-winded article on my website with the details, but the highlights are: The accuracy of the simulation depends on the numerical integration scheme used and the size of the time step used in the simulation. Using a numerical scheme with a high order of accuracy makes it possible to achieve very good accuracy while taking large time steps (less than 1 cm error after an orbit of Kerbin, with time steps larger than ~20 s). At least up through a fifth-order Runge Kutta method (which is as far as I went), there is always a big gain in efficiency in going to higher-order methods. (By which I mean, the higher order methods get increasingly costly to calculate per time step, but they allow much larger time steps to be taken so overall less computation is required to simulate a given length of trajectory.) The maximum time step that can be taken for a given amount of error depends strongly on the trajectory -- lower orbits and more eccentric orbits require much shorter time steps than higher ones. Orbits of Kerbol further out than Jool can use time steps of several millions of seconds, as contrasted with time steps of ~20 s for low Kerbin orbits. Using an embedded integration scheme that can adjust its time step to maintain a certain error level is advantageous. I found Dormand and Prince's Runge Kutta method RK5(4)7M to work very well. This half-way approach (planetary bodies on Keplerian trajectories and vessels on Newtonian trajectories) doesn't seem to have Lagrangian points. The difference between a Newtonian trajectory and a Keplerian orbit is pretty small for low orbits, but the difference between them grows quickly as orbits get higher, especially for planets with moons. Therefore, if Newtonian trajectories are implemented, each planetary body could have its SOI shrunk to a fairly small radius. Inside the SOI, Kepler's laws apply and orbits would be perfectly stable with no perturbations. Outside of any SOI, in no-man's-land, Newton's laws would apply. With this approach, the time step size needed for good accuracy is always large enough that 100,000x timewarp is possible even if trajectories for a large number of objects need to be calculated. The trajectories should be calculated ahead of time, so that they can be displayed in map view. Interpolation inside of a time step is very fast and accurate using Shampine's method of finding an additional solution for position and velocity at the midpoint of each time step and then creating fourth- and fifth-order interpolating functions. The interpolated state can be used to provide the position and velocity of a vessel at each frame and to pinpoint certain points in the trajectory (closest approaches to a target vessel, etc.). Whenever a vessel accelerates the precalculated trajectory would have to be thrown out and a new one calculated, but usually only one vessel is accelerating at a time so it would not be a serious problem.

HarvesteR, it sounds like forces and collisions between parts make up the bulk of the physics calculations (and they're certainly the ones that go wrong at high physics warp!). Have you considered a sort of intermediate physics warp in which the ship is treated as a single rigid body? The ship would be 'frozen' in it's current shape, so there would be no need to calculate forces between parts or check for collisions, and the number of physics frames that can be calculated per second should go up significantly. It would make things much easier for the folks who want to use ion engines. The warp could be disabled automatically whenever the ship is in atmosphere, has acceleration above some low limit, or comes close to another ship -- all cases where inter-part forces and collisions should be calculated. It seems plausible to me from a computational standpoint, but I don't know how much freedom Unity gives you to do things like that.

I tried using those legs on an orbital-debris-cleaning craft, where the legs could extend to form a sort of cage to hold debris that doesn't have a docking port. I never got to even try capturing any debris. Three craft in a row, when switching to the vessel in orbit the landing legs broke off and floated off at ~10 m/s. (I then switched to using the electromagnet in the Kerbal Attachment System. That fourth cleaner craft worked, and most of the debris it had to clean were those !?#! landing legs!) I don't know where the bug lies (physics engine? loading routine? part model?) but there's definitely a bug; it's not just you! I now avoid using those legs at all; so far the smallest- and largest-size legs haven't given me any grief.

Yes, that was one of the motivations for my suggestion above. By restricting the use of n-body physics to regions where gravity and the gradient of the gravitational force are small, it should be possible to use relatively large time-steps when integrating a vessel's trajectory so that the paths in map view can be drawn without too much computational effort. I think the real reason for using patched conics is that they're good enough and they're much easier. Squad is wisely expending their efforts improving other parts of the game that need much more urgent attention.

Yeah, my arguments are mostly that it wouldn't really be worse, which is not exactly a strong argument for changing to a different system. The only thing it would enable that we don't have now is, I think, the Lagrange points. And I'm sure Squad could come up with an easier way to implement those if they really wanted to do so. It would be fun to try something different like that, but I doubt there's any way to get into the physics engine part of the game through mods.

An idea that's been bouncing around in my head to add n-body physics without too much pain (for the player and his or her computer, at least) is to introduce "no-man's land" in the space between bodies in the Kerbol system. Right now, every bit of space in the game is included in one body or another's SOI. My idea is to shrink each SOI drastically and leave the area outside of the SOIs as no-man's land. Inside a body's SOI, each craft follows a Keplerian trajectory ("on rails" as it is now), and in no-man's land each craft's trajectory follows n-body physics or some approximation of it. (The game might want to account for only the influence of the two or three bodies with the strongest gravitation at any given point, rather than account for every body in the system every time.) With this approach, craft in reasonably low orbits around a body still have stable orbits because they're on Keplerian rails, just as you'd expect. For craft in no-man's land, errors that creep into their trajectory due to rounding don't matter so much because their trajectories are expected to be perturbed anyway. It's relatively easy on the computer to integrate a craft's trajectory in no-man's land (for plotting in map view or for traveling at high time-warp) because the integration is only done in areas with relatively low gravitational acceleration. That allows large time-steps to be used while maintaining reasonable accuracy. The SOIs can be set up to ensure that each body's Lagrange points are in no-man's land, so L-points will work as expected. A couple folks mentioned the number of parts in a typical craft as a problem. But the acceleration can be calculated based just on the craft's center of mass (COM), just as currently the craft's COM moves on Keplerian rails. But it wouldn't be so hard to include tidal effects on a craft, by calculating the gradient of the gravitational field at the craft's COM. That first-order approximation can be used to calculate the gravitational force on each part based on the part's COM relative to the craft's COM. It would be neat to see, although it might not make much difference since each craft's rotation is cancelled out when going to time-warp anyway.

Have you seen the weekly challenges posted on Reddit? I recently discovered them and am trying to go through them in order. The earliest challenges (over a year old, now) are not quite so challenging any more, as the game has grown since them. You can ramp the level of challenge up or down by deciding how closely to follow the spirit of the challenge (e.g., whether to use the more-recently added parts or mods). Though, the challenges that involve particular Easter eggs, such as week 4, can be difficult when the recent updates put them underground! There's a list of past challenges here: http://www.reddit.com/r/KerbalSpaceProgram/comments/zfhn0/all_weekly_challenges/

My thanks as well! I just installed MapSat in my new install of 0.21, made sure to enable autoupdate of the hilo.dat file, and couldn't figure out why my map of the Mun was mostly white. I guess this means I have to run the mapping mission again now ... Also, I can confirm as well that at least the two munar arches near the equator are still visible on the surface. I made low passes over both of them while searching for a munolith. (And still haven't found a munolith; I kind of crashed while trying to land at one likely location and nearly lost Jeb...)

ecat, that's about the same thing I start thinking when I read these threads on physics engine performance, or improving framerate, or what should be added to the game next, etc. Yes, better performance would be better. Yes, the things that Squad will add in the next version (or that they previously planned to add next, such as resources) would be good additions. But the core of the game, in both game modes, is constructing and then simulating craft. It needs to be solid. Problems with this core can't be overcome by adding other features. The fact that bugs (from misplaced parts in the VAB to random explosions on load to numerical instability under physics warp) seem to be allowed to persist is what is worries me the most regarding the future of the game. The number of bugs like this usually isn't static. Either they're being tracked down and fixed, or they are multiplying as more things are put on top of the core of the game. edit: That said, I have a background in numerical simulation and what stands out to me the most are the physics bugs. I don't know PhysX, but I would hope that it's not a complete black box and that it is possible for Squad to do things differently to fix some of the simulation problems. In CFD (computational fluid dynamics), commercial codes often try to be black boxes that 'just work' for everyone and every problem. The result is often completely unrealistic results without the user realizing it or simulations that just won't run for unknown reasons. To really have confidence in a code you need to know exactly what it's doing numerically, which usually means using one that's open source or writing it yourself. I see some parallels to PhysX in KSP. I wonder if anyone at Squad has much experience with numerics.

I've been having the same problem (or at least a similar problem) with the latest version. I've only been flying some pretty simple craft, but consistently if I switch away from a craft in flight and back to it, any LT-1 landing struts on it break off and drift away. I have one craft that's landed on the Mun on LT-1 struts and it seems to be fine. It's frustrating; I just sent up a tug that uses the landing struts as a claw to grab some debris around Kerbin to deorbit it, and instead the struts are just adding to the debris! The only mod I have installed is MechJeb.

Err, I think you have that backwards. Under the same conditions, LH2/LOX gives a higher specific impulse than RP1/LOX, both in atmosphere and in vacuum. (RP1 = Rocket Propellant-1, essentially kerosene). Have a look at the big table about halfway down the Wikipedia page on liquid rocket propellants, here. V_e, effective exhaust velocity, is proportional to specific impulse (just higher by a factor of g). You can see that the specific impulse for LH2/LOX is approximately 30% higher than for RP1/LOX when exhausting to 1 atm pressure, and approximately 27% higher when exhausting to vacuum. In fact, RP1/LOX suffers proportionally more when exhausting to 1 atm pressure, its ISP being reduced by 16% while LH2/LOX loses only 14%. Topic drift! The conversation went in an interesting direction.

I started playing KSP with version .18, and I've never seen a reference to liters in the game itself. I think the volume unit makes the most sense if you take it as being equal to five liters. Then, the liquid fuel and oxidizer densities work out to about what you'd expect of kerosene and liquid oxygen, and the capacities of the fuel tanks match up well with their sizes. Closer to the original topic of the thread, it would be awesome to have an engine like the LANTR in the game, to be able to trade off ISP and thrust as needed.

My favorite video is Odyssey of the Astraeus, by allmhuran: http://youtu.be/pFfXAmVkY_Q His ship design and his piloting of it are really impressive, and the video is just so well put together. With the choices of music, many of the space shots are just beautiful.

Hi TChapman, I've seen similar discussions about fuel density and tank capacities come up on the forum a couple of times before. There is a simple explanation for your findings regarding kerbal fuel densities: the unit of volume in KSP is not liters! Despite their common usage on the forums (and despite the fact that KSP uses meters for length, tonnes for mass, kiloNewtons for force, etc.), the unit of volume is not quantified in the game. I've seen the unit of volume referred to as a 'fuel cubit' (maybe that should be 'kubit'), and the numbers all make much more sense if you use a volume unit of five liters (i.e., 200 kubits = 1 m^3). Then, voila! The fuel densities are no longer five times higher than expected, and the capacities of the fuel tanks are no longer five times smaller than expected. I don't know why the volume unit was chosen that way, and I do wish the developers would change the unit to liters, as it would eliminate some confusion. If there's anything in the game itself that does identify the volume unit as a liter I'd like to hear about it, but I don't believe there is.