semi-active physics for aerodynamic decay on unfocused objects

[thereaverofdarkness]

I am both suggesting implementing this and opening the thread to discussion of the impacts of such a thing and how you would feel about its implementation.

The basic idea is to have unfocused objects in atmosphere slow down and thus change trajectory using a very simple calculation, treating the craft/object as a single part with a total mass and averaged drag, and no other special defining characteristics. Its trajectory would then be predicted beforehand and it would merely run on rails.

This would allow you to perform light aerobraking maneuvers more quickly by unfocusing the craft so you can go to higher time warp, and would also allow you to de-orbit staging debris over time by placing it in an orbit that intersects the atmosphere. You could intentionally set your initial staging orbit at 65km so that the spent parts left behind de-orbit rather quickly.

For those of you who believe this would cause a lot of lag: it really wouldn't be significantly increasing cycles, for two reasons:

1.) trajectories are predicted beforehand and move on rails, just as they do outside the atmosphere

2.) things in atmosphere will gradually clear out, so you won't have to worry about a build-up

[AlexanderB]

...and this would probably also open the door for adding parachutes and having it parachute safely to the ground on rails.

[edit:] and ion drive while on rails/warp..

Edited August 31, 2014 by AlexanderB

[dryer_lint]

I agree, I was just thinking about this a while back... however, aren't most orbits in KSP completely outside the atmosphere?

[Eric S]

Show your math, rather than calling it a simple calculation. While I'd like to see it, I'm skeptical that such a formula exists that fits into KSP's "on-rails" trajectory projections. Bonus points if it matches fully simulated trajectories using stock aerodynamics (I don't think this would work at all with NEAR or FAR or any other semi-realistic aerodynamics simulation, because orientation would matter).

Yes, MJ can do aerobraking calculations, but it does that using an iterative solution which is more computationally intensive than KSP's "on-rails" trajecotry projections.

[tntristan12]

Yes, you should probably quantify your method. However, I am aware that such models exist. I don't know the specifics of them though.

By the way, Eric: in physics and engineering such things are rarely one line equations, and the word "formula" is discouraged. I would like to see the OP's derivation.

[Kasuha]

The calculation may be iterative and relatively computionally intensive, but for an unguided object on rails it can be done once and then cached until that object's trajectory changes or the object hits the surface. So I'm not very concerned about performance.

I'm more concerned about accuracy of such prediction. It can easily be "abused" for saving and recovering parts which would not survive when followed.

[Eric S]

By the way, Eric: in physics and engineering such things are rarely one line equations, and the word "formula" is discouraged. I would like to see the OP's derivation.

That is true, I wasn't thinking in terms of the formal definition of a formula, more process. Lack of caffeine defense? I also wasn't thinking in terms of caching, and that would help as Kasuha pointed out, since we're talking something that isn't focused, so you wouldn't be recomputing the entire future trajectory if it's under thrust. I still think calling it a simple calculation makes it sound more trivial than it would be to implement, but it might be less than a major project, at least.

[tntristan12]

Agreed, it would not be a small feature and it'd be a challenge to avoid making it abusable. I still feel like when we can have proper multithreaded physics, a background simulation can be run on in-atmosphere objects. When you get down to it, there's almost never more than half a dozen objects in the atmosphere at any given time. It wouldn't be unreasonable to force the player out of time warp and warn them that if they engage time warp the in-atmosphere objects may be lost

[Kasuha]

When you get down to it, there's almost never more than half a dozen objects in the atmosphere at any given time.

Apart of some rare exceptions, parts in the atmosphere are parts that came off the ship you're piloting just now so running physics simulation on them is not putting more load on the physics engine. The problem occurs if you want to use time warp. Even physics time warp does not go well with using parachutes to land things safely. And non-physics time warp is completely out of question until they are landed.

Also, the game not allowing you to increase time warp because you still have some parts falling through the atmosphere might be major inconvenience for players.

[tntristan12]

Also, the game not allowing you to increase time warp because you still have some parts falling through the atmosphere might be major inconvenience for players.

Agreed, totally. However it does not have to be an all or nothing solution (full time warp or completely restricting it). I had in mind a message kind of like the popup that comes up the first time you engage physics warp ("might make ships unstable"). It tells you that objects are in atmosphere, you can use physics warp (and perhaps increase the range of physical warp values when the controlled vessel is not in atmosphere) but if you go into standard warp the game will revert to classic behavior ("warning: engaging warp will pause the current aerodynamic simulation for $vessel").

I don't think it'd work out to be a huge inconvenience because, like you said, objects in the atmosphere are usually parts dropped from the ship you're piloting right now, and during ascent you don't really need time warp. In other cases where you have returning debris from a previous path (for example if I set a free return trajectory and lose some debris) I might not care if the debris disappears in the atmosphere, so when the warning pops up I just ignore it and time-warp on. No harm, no foul.

The good thing about approaching it this way is that it's a *full* physics simulation that can't really be exploited. It pleases those who want to be able to recover separate vessels away from the control ship, without punishing people who just want to get on with their mission and don't care if the upper stage booster they dropped 10 minutes ago disappears or crashes. Some config settings could change the robustness of this feature. Perhaps a checkbox would prevent the warning popup from happening if the object entering the atmosphere is debris. Another slider could limit the maximum number of parts that are simulated at a given time.

My point with this monster of a post is that there are options that preserve the current gameplay while still giving folks this much requested feature. Also, allowing off-screen recovery would be a fantastic addition to career mode gameplay.

[arkie87]

Apart of some rare exceptions, parts in the atmosphere are parts that came off the ship you're piloting just now so running physics simulation on them is not putting more load on the physics engine. The problem occurs if you want to use time warp. Even physics time warp does not go well with using parachutes to land things safely. And non-physics time warp is completely out of question until they are landed.

Also, the game not allowing you to increase time warp because you still have some parts falling through the atmosphere might be major inconvenience for players.

I think OP intended that rather than simulating physics using PhysX engine, the trajectory will be calculated separately using a custom ODE equation the solution of which will be used to modify the trajectory, thereby ignoring what patched conics predicts (is that possible?)

This would mean all simulations can be performed whenever and time warp isnt a problem (as long as the simulations are completed before time warp is entered).

For stock aerodynamics, since drag is independent of orientation, the calculations would be simple and 4th order Runge-Kutta integration can be used to obtain accurate predictions with very few points (probably between 100-1000) which is trivial on any computer made this decade. This scheme can be implicit (iterative) or explicit (non-iterative).

For NEAR or FAR, an assumption will have to be made about the piloting, most notably the Angle of Attack (constant angle of attack can be abused since the craft might not be able to maintain it if it doesnt have enough torque or if the vector is unstable) . Thus, more likely, the player will have to choose prograde or retrograde, or NEAR/FAR will automatically enforce the most stable orientation (retrograde for pods, and prograde for aircraft).

Nevertheless, if the angle of attack is given, the problem is the same as stock KSP, and 4th order integration schemes can be used no problem.

[Kasuha]

I think there are two easy solutions:

One easy solution is to let the part/ship disappear and provide the player full recovery bonus including crew as if the part/ship has safely landed.

The other easy solution is to run full physics simulation of the part's fall.

Besides these two, there is a range of solutions in between which have some strengths and weaknesses of either of the two extremes, neither is in reality any better than them and are actually even harder to implement.

[arkie87]

I think there are two easy solutions:

One easy solution is to let the part/ship disappear and provide the player full recovery bonus including crew as if the part/ship has safely landed.

The other easy solution is to run full physics simulation of the part's fall.

Besides these two, there is a range of solutions in between which have some strengths and weaknesses of either of the two extremes, neither is in reality any better than them and are actually even harder to implement.

Your solution is fine for players who dont want to simulate aerobreaking or orbital decay. But i agree, if we are just looking for a landing and receiving credit for parts, than simulating physics is a waste, and the player should just get their recovered parts/kerbucks.

Personally, i think something like what i proposed above would be great for a plugin to perform an aero-breaking prediction and should be FAR/NEAR compatible (it wouldnt manually change the path from what patched conics predicts, it would just show a prediction). I could easily program it in a fake language like MATLAB, but not so much in C#....

[tater]

For anything the game labels as "debris," if the "on the rails" path intersects the atmosphere height, it should simply disappear unless the player is actively focused on it or it is inside physics distance (then physics apply). It would at least encourage deorbiting junk as a way to keep things clean, as well as to minimize the amount of stuff that the game needs to watch.

[arkie87]

For anything the game labels as "debris," if the "on the rails" path intersects the atmosphere height, it should simply disappear unless the player is actively focused on it or it is inside physics distance (then physics apply). It would at least encourage deorbiting junk as a way to keep things clean, as well as to minimize the amount of stuff that the game needs to watch.

What for? Players can get rid of debris by clearing it in tracking station, so there is a way around this requirement?

[tater]

Yeah, I know, it's sort of a pain. It gives the feeling of having to explicitly do something, when the fact was that you dumped them such that they followed you down. Anti-immersive, but not critical.

[arkie87]

Yeah, I know, it's sort of a pain. It gives the feeling of having to explicitly do something, when the fact was that you dumped them such that they followed you down. Anti-immersive, but not critical.

Oh, i see. you are saying the opposite. Right now, they wont get destroyed without you manually deleting them, and you are saying, the game should automatically delete them for you, since you went through the trouble of making sure they re-entered atmosphere.