background processing of non-controlled vehicle physics when in lower atmosphere

[CorvusCorax]

Background:

Currently, physics (atmospheric drag, collissions, ...) are (to my understanding) only calculated for the currently controlled craft and objects within a 2.5 km radius around the currently controlled craft. Objects further away undergo a simplified "on-rails" background physics, not using the unity engine. These background physics are extremely simplified (no drag in upper atmosphere, instant destruction in lower atmosphere) which severely impacts gameplay:

Problems:

1. Jetisoned stages cannot be recovered, because they destroy instantly in the lower atmosphere despite recovery measures outside of the 2.5 km sphere while the player is busy with orbital ascend and still in upper atmosphere (and thus cannot switch to other vehicles) - this severely hampers any manual "re-usage" attempts (putting parachutes on stages, etc...) especially in early game in campaign mode, where self-recovering solid boosters are unavailable and a single stage to orbit approach is not feasible due to weight and parts limits
   
2. Probes and vehicles that rely on atmospheric drag for reentry require "babysitting" in every orbit to ensure orbital decay.Gameplay example: I accidently sent a Kerbal on a suborbital flight in a low orbit instead (periapsis is at 64km in upper atmosphere, apsis is in outer space) using all the fuel. Now I need to switch to that craft once every (in game) hour to have it the active craft in order to have the orbit descent. If I use time warp and don't do that, the orbit stays just as it is
   
3. One can exploit this behaviour to make impossible orbits (periapsis just barely above lower atmosphere, apsis just so barely in space) switch back to the space complex while the game lets one do it (while the craft is just above 70km on Kervin) and have it orbit like a cold war CIA spy sattelite (except the latter would re-enter latestly after one orbit)
   

Possible solutions:

1. Process crafts simultaneously even outside the 2.5 km bubble

Pro:

• although timewarp would need to be resricted to 4* while theres objects in need of processing, this seemingly solves the issue
  

Con:

• Unity's precision depends on the distance to the origin, which therefore is most likely set to the currently active craft to prevent floating point accuracy issues. Calculating physics for objects far away would end up being unfeasible and most likely tear them apart instantly, even if the player is still at the same planet (which he might not)
  

2. Immediately auto-switch to other craft to make it the unity - origin

If the player is in fast timewarp or on the ground tending the spaceport, the game could alert the player that a craft is about to enter the upper atmosphere and needs babysitting - and then switch to it in off-rails mode

Pro:

• no significant changes to the game engine needed, solves the accuracy problem.
  

Con:

• Does not work if the player has more than one craft in that condition - which would be the case with spent stages supposed to be recovered
  

3. Like two, but asynchronously. The player is force switched to every affected craft, but one after the other, until all are safe (in space in and in orbit) or landed

Pro:

• seems like a good idea on first glance
  

Con:

• bores the player to watching the same descent and subsequent crash of every discarded rocket stage over and over again for every launch - although fun the first 2 times definitely a bad idea.
  
• Time-space paradoxon issues: What if the player first watches a stage get to safety, then later watch a second stage re-enter the first's 2.5 km sphere and crash it before it safely got to the ground (or with controlled vehicles - does it deliberately) - this opens a can of worms in comparison to which implementing general relativity would be easy
  

4. Open a background task with a separate unity instance to calculate the physics of each non-controlled craft simultaneously. Objects that are close to each other (2.5km sphere) would be calculated by the same unity instance to cover collissions and the like.

Pro:

• using a separate task/process either for each "background object" or for each "cluster of background objects within a 2.5km radius" with a separate instance of unity solves any issues the engine might have with multithreading, as its in fact not multithreaded and more like the game is running several times simultaneously in the background
  
• those unity tasks are "headless" (batch mode) - which saves processing power which would otherwise be needed for graphic effects, and possibly allows much higher frame rates (and as such faster accelerations than *4 warp) up to the point that the background process results are available almost instantly without affecting the game in foreground
  
• this is therefore NOT the same as multithreading (which is on the do not suggest list for valid reasons) - the game itself does not have to become thread safe, just needs a layer of inter-process communication (see cons for details)
  

Con:

• a separate task needs to be spawned - or even a seperate program started by the main game when needed needs to be implemented. Although the code from the main game could be reused with minor modifications, it would take a day or two to get the infrastructure and inter-process communication needed for that implemented (mainly the game needs to start a background process, tell it the object(s) to load and in what situation they are in when they go off rails, and would receive back the resulting situation (new orbit, landed, etc... to go back on-rails)
  
• if there are many "background objects" in game simultaneously, the number of spawned background processes could impair the main games performance temporarily and cause frame rate drop or lag. This can possibly be prevented by throttling the to be spawned background processes with a lower task priority, but might still prevent-or-temporarily-reduce high time warp levels until the background processing is complete
  
• this is a complex solution that needs to be implemented properly from a software architecture point of view to not cause issues with third party mods or future enhancements. for example if mods are interfacing with unity, those same mods would have to be loaded into every instance of those background processes as well.
  

5. Make a simplified on rails background calculation for both upper atmosphere:

As suggested here, the behaviour of the craft could be aproximated. There's many subvariants possible:

a) impose a fixed delta-V on every orbit in upper atmosphere like tater suggested

impose a dynamic delta-V in upper atmosphere based on a simplified calculation based on atmospheric drag and a fixed drag/weight ratio

c) impose a dynamic delta-V in upper atmosphere based on a slightly more advanced calculation of atmospheric drag using the actual mass of the craft and simply add up drag of all components (fixed drag/weight ration but calculated on vehicle parts)

Pro:

• Easy to implement
  

Con:

• Due to the limited accuracy, mIght allow cheating to get better or worse behaviour on-rails than when actually on the craft (unlikely to be a big problem though)
  

6. Like 5, but also simplified calculation for lower atmosphere

It could be calculated if 1. the vehicle has chutes, and 2. the amount of chutes to weight leads to a terminal velocity prior to impact below any of the parts, or something like that. and if so, simply place the thing on the ground safely

Pro:

• Easy to implement
  

Con:

• Much higher cheater potential since this simplified calculation would let crafts land that would ordinarily topple over after touchdown and loose hull integrity. I had many a rocket stages glide nicely down to the planet surface or ocean, then on touchdown the chutes go away, the rocket falls over and explodes in a giant fireball (much like how it happend in real life to SpaceX ocean landings )
  

7. Like 5 but suspend descent on hitting lower atmosphere

Objects that hit lower atmosphere while on-rails could simply be suspended in midair until made active again. This feature should be limited to

1. crafts with a command module of any kind that can be activated by the player (pod, or stayputnik, or similar, wouldn't have to be currently active, just needs to be there) - this would allow the player to do a powered descent for example

2. crafts with parachutes attached that are already triggered (for example if they were triggered previously during the staging sequence, for example on stage separation)

While discarded stages and other objects with neither of those to be true would still silently be deleted

Such a "suspended" object would stay in its place over the planet surface (rotating with the planet) similarly to crafts that are already in "landed" state. Unlike the latter they cannot be recovered yet, but they could be made "active" by the player switching to them. If that happens, they continue their descent on Unity physics (although to a later time than it would ordinarily have happened but that should not affect the outcome)

IF the currently active object comes within a 2.5 km radius, that could (but doesn't have to) also trigger the activation of that object

Pro:

• Also very easy to implement
  
• Outcome of landing is very realistic
  
• It doesn't happen to "space junk" - only to crafts of importance, like deorbited spacecraft or stages that are actually supposed to be reusable
  
• It would prevent the player from loosing a spaceship with a pilot just because he timed two of them to deorbit simultaneously (as one of them would enter suspended state)
  

Con:

• The suspending until reactivation could lead to a few weird effects, like deorbiting at night but leaving it suspended for a longer period, and later landing the vessel at daytime. (Although I don't really see it as a big problem)
  
• There's a very unlikely chance that the player could change the outcome of the deorbit by changing the surroundings while a craft is suspended (For example, placing another vessel or structure underneath that would provide a landing platform instead of a water landing, or cause a collission. (I also don't really see that as a big problem)
  

Suggestion:

please implement one of those solutions in the future :-) (Originally I was suggesting solution 4, but after reading the comments I think I'd almost prefer 7)

Edited January 13, 2015 by CorvusCorax
more, better solutions

[ddenis]

Problems:

• Probes and vehicles that rely on atmospheric drag for reentry require "babysitting" in every orbit to ensure orbital decay. Gameplay example: I accidentally sent a Kerbal on a suborbital flight in a low orbit instead (periphrasis is at 64km in upper atmosphere, apsis is in outer space) using all the fuel. Now I need to switch to that craft once every (in game) hour to have it the active craft in order to have the orbit descent. If I use time warp and don't do that, the orbit stays just as it is
  

I'd delete this problem, because:

1. To know when to finish aerobraking I'd need to babysit the craft, because I won't calculate how many orbits are necessary to slow the craft enough.
   
2. If in this time warp is limited to 4*physical, I'd rather babysit my craft during aerobraking, then watching as my another craft slowly flies through space in the middle of nowhere.
   

Also, you could be interested in [WIP] Principia: N-Body Gravitation and Better Integrators for Kerbal Space Program. That's what I'm waiting for.

From link above.

Though I don't think N-body gravity would significantly affect any planetary orbits in terms of gameplay, I do worry that making low orbits unstable would make the game less fun. I know stationkeeping is a planned feature, but that's a whole layer of complicated code that needs to be written to make Principia playable without untenable levels of orbit management.

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.

Edited January 9, 2015 by ddenis

[Damien_The_Unbeliever]

The problem I can immediately see with 4 is you say "cluster of background objects within a 2.5km radius" should group together but you could end up with pathological situations where you have chains of as many objects as you like, each (say) 2km away from each other, but obviously the ends of the chain are far further away from each other - So do you either end up with a single "cluster" that is in fact 50km wide, or do you somehow partition them into pairs of objects? - That each object within a pair is within 2km of its partner object, but is also within 2km of another object that is being treated completely differently?

[Synapse]

The solution to spent stages is to enable a timer (say 10 in game minutes) where discarded stages are still physics-capable.

The solution to constant orbits below the atmosphere when not player controlled, is to use a simple formula rather than a complex one to calculate drag. For example, just 3 atmosphere formulas 1. high drag 2. medium drag 3. low drag

[vexx32]

In all honesty, I can't consider any of these a proper solution to the problem. All proposed ways of doing it are either tedious or very resource-intensive; this is essentially the exact reason the current workaround exists, even though it is arguably a very simplistic workaround that needs thorough revision.

A better method would be to give orbits that dip into the atmosphere some provision even in the on-rails calculation, perhaps simply decaying their orbits by an amount that depends solely on the density gradient of the atmosphere. It's not super realistic, but it will solve the problem to some extent. If we remove the 'killzone' with some form of recovery calculation -- it would need to determine whether the craft, without control, is able to land safely under reasonable conditions, perhaps just figuring out how many active parachutes it has compared to its total weight and checking the final expected velocity against the impact tolerance of the parts -- this would be perfectly fine for most situations.

Certainly, it's not perfect, but it's both less resource intensive and likely a simpler implementation overall.

[tater]

The solution to spent stages is to enable a timer (say 10 in game minutes) where discarded stages are still physics-capable.

The solution to constant orbits below the atmosphere when not player controlled, is to use a simple formula rather than a complex one to calculate drag. For example, just 3 atmosphere formulas 1. high drag 2. medium drag 3. low drag

Yeah, something, anything would be better. It could even once every day, XX hours, whatever, lower any orbit that touches an atmosphere by 1000m (drop apoapsis and periapsis by that amount, or whatever). If any such drop puts both peri and apo inside the atmosphere, the object/vessel is deorbited next time it polls.

It would be nice if astronauts could at least reenter by themselves (pilot skill?) as long as they are in a command pod and it has chutes.

[CorvusCorax]

I just found another, possibly related problem.

In a hypothetical scenario where you try to orbit/de-orbit but run out of fuel with both periapsis and apoapsis lets say between 68k and 70k (but not above), you will be stuck at 4x warp and cannot switch back to the spaceport or to any other vessel (the button is disabled)

However even at 4* warp, such an orbit has so little drag, you might have to wait for many real-time hours until the deceleration becomes strong enough to cause deorbit.

(unrelated: The case that I actually encountered I had an apoapsis much higher, so I was able to eventually deorbit by doing other missions until I could upgrade the astronaut center to allow in-orbit EVA's - then sending the pilot into EVA and pushing the rocket by means of the pilots EVA rocket pack until the periapsis was low enough to deorbit quickly. (old Kerbion praxis: If you run outa fuel, go out and push!) I think you *might* actually have unlimited delta V this way, if you re-enter the craft and do another EVA, the space-suit is gonna be refilled with 5 fuel each time (unless that comes out of the command pods monopropellant storage?) - similarly you could deorbit a any crft out of fuel in low orbit by "ramming" it at apoapsis with a space probe with suitable thrusters)

however all of these techniques would be unavailable if the craft never leaves upper atmosphere anymore, as you cannot switch crafts and are limited to 4x warp. I think there isn't even a self destruct of any kind for early game active craft (although you might be able to just quit the game, would that bring you back to space port?)

I am adding more proposed solutions to the above list based on the suggestions

[Darnok]

Suggestion:

please please implement solution 4 in the future :-)

Why?

MechJeb can calculate landing site in atmosphere... why not use this mechanic to calculate debris/dropped stages trajectory, while they are still in 2.5km zone, and put things "on-rails" later?

[CorvusCorax]

yeah I changed that, there's a new, imho better suggestion based on what everyone else said

[rkman]

Why?

MechJeb can calculate landing site in atmosphere... why not use this mechanic to calculate debris/dropped stages trajectory, while they are still in 2.5km zone, and put things "on-rails" later?

Would be useless in the vast majority of cases, where dropped stages in the atmosphere are at a distance much larger than 2.5km.

[Darnok]

Would be useless in the vast majority of cases, where dropped stages in the atmosphere are at a distance much larger than 2.5km.

No, because you can calculate debris path, save it, and then it just move this part of ship using calculated path. Those calculations also should include point when it hits ground, so even if you time warp it should hit ground and explode not just be deleted.

[rkman]

No, because you can calculate debris path, save it, and then it just move this part of ship using calculated path.

I see. Yes that should work. Might cause momentary performances issues though when there is a large amount of debris.

[Scoundrel]

Just a thought re: debris/stage recovery...

Would it be acceptable if, say, a chunk of debris has a parachute part that is deployed - or an undeployed chute and probe core - would be "auto recovered" (after, say, 2500m) if the periapsis is below 70km or whatever the atmospheric boundary is for whichever body said debris is being ejected?

[tater]

Yeah, manned vessels that can survive and have chutes should be able to do so without player intervention (or focus).