Kerbal Space Program

-- DESCRIPTION --

When the physics time step becomes too large, collisions with the ground are missed and/or over-penetrate. This happens if the frame rate drops too low or time acceleration is enabled when the computer system cannot keep up.

This manifests in several ways that all appear to be related:

• Vehicles, debris and Kerbals will drop through the ground unexpectedly and fall into the void.
• Kerbals on EVA will die unexpectedly because their feet become lodged in the terrain. The Kerbal still animates as if he were walking, but cannot move from the current position. When returning to KSP, the Kerbal is marked as "Lost".
• Lander feet will penetrate the ground and become lodged on the opposing side of the polygon making it impossible to take off.
• Parked rovers will suddenly puncture their tires or explode when tabbing between craft.
• Rover tires and landing gear rapidly move in and out of ground contact, generating unexpected torque.
• It becomes possible to quick-save while a rover is in motion because the tires have been forced out of contact; even though they appear to the player as in-contact.
• Loading a quick-save of a vehicle that was out-of-contact causes it to explode on load.
• Vehicles are less affected by ground friction, presumably because they are more likely to be momentarily out-of-contact.

==================================

-- STEPS TO REPRODUCE --

This can be reproduced in any way that significantly impacts the frame rate, but the easiest way to reproduce:

• Create a moderately complex ship or rover. (Rovers seem more affected, but both ships and rovers work.)
• Allow the crew to exit the craft and place them on EVA nearby.
• Create a second moderately complex ship or rover.
• Navigate the second craft into the immediate vicinity of the first craft.
• Continue to navigate additional craft into the area until the physics frame rate becomes impacted.
• All of the ships will drop through the terrain; or Kerbals on EVA will die; or other symptoms as mentioned above.

Easiest way to save an a out-of-contact ship:

• Drive a rover in similar conditions as listed above.
• Tap F5 repeatedly while driving.
• Hold F9 to load the quick save.
• The rover will explode.

==================================

-- SYSTEM CONFIGURATION --

On my system, the limit seems to be about ~800 parts in the immediate vicinity, particularly if the parts list contains a large percentage of struts and wheels. The parts don't need to be on one craft, just within simulation range.

Here are my system stats:

Processor Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz
Memory (RAM) 8.00 GB
Graphics AMD Radeon HD 5800 Series
Gaming graphics 4859 MB Total available graphics memory
Primary hard disk 840GB Free (931GB Total)
Windows 7 Ultimate
Manufacturer Gigabyte Technology Co., Ltd.
Model P55M-UD2
Total amount of system memory 8.00 GB RAM
System type 64-bit operating system
Number of processor cores 4
Total size of hard disk(s) 931 GB
Disk partition (C:) 840 GB Free (931 GB Total)
Display adapter type AMD Radeon HD 5800 Series
Total available graphics memory 4859 MB
Dedicated graphics memory 1024 MB
Dedicated system memory 0 MB
Shared system memory 3835 MB
Display adapter driver version 13.251.0.0
Primary monitor resolution 1920x1080
DirectX version DirectX 10

I try not to have too much running in the background.

==================================

-- NOTES --

I don't know anything about your code so take this with a grain of salt: One technique that's worked for me in the past is to use two simulations: the "fancy" simulation with all the bells and whistles, and a secondary very high frame rate simulation that's nothing more than a rigid body simulation of the convex hull for the purpose of swept-hull collisions. The swept-hull simulation is only used to calculate the time delta of any potential collisions before they over penetrate; the primary simulation is then run to that time delta instead of a full frame. This seems to work better than rewinding or heavy de-penetration forces. If you use a Verlet integrator for the second sim, you can keep it in sync with the primary simulation because Verlet lets you cheat the position without problems. The fact that it's second order doesn't matter because you're only going to run it for a fraction of a frame before re-syncing, and it won't diverge in that amount of time. Again, that's just me and I'm not working with the same code, so I understand you may have a better technique. You know your engine best!!

Thank you for such an awesome game!