Blog

This is full-custom code like everything else in the game and the supported features are consequently rather limited. In comparison physics engines provided by popular middleware and libraries are way more advanced. However I’ve always preferred simple systems I do understand to ready-to-use black boxes I don’t. I know this is very counter-productive but for once the topic is well documented online, especially if older technologies and algorithms will do.
Incidentally when performance is a key point I’ve noticed in multiple occurrences that techniques from the 90’s and 2000’s can be extremely interesting. Back in those days developers could not rely on the amazing computing power a modern PC can deliver. So it appears they clearly “knew a thing or two” about optimization and efficient designs!

Implementation points

Detection

Collidable shapes are approximated using swept-sphere volumes. Basically this includes spheres, capsules (cylinders with hemispherical caps) and rounded boxes, to which I added a “disk” based on an octagonal primitive to better model flattish cylinders. Obviously these volumes can’t provide the fidelity of a collider mesh but are way faster to compute with.
All game structures automatically build their associated collidable shapes and group them under boundary volumes to form a global tree. At a larger scale the spatial partitioning is directly inherited from the gravitational spheres of influence (galaxy systems then celestial bodies).

Collision response

The system relies on a “penalty-based” approach which inserts temporary damped springs at contact points. This requires to properly integrate the related forces and moments. To that end the collision detector must be fully merged into the physics integrator to continuously provide the springs’ states. Moreover the time step of the integration must be tightly adjusted to sample the springs’ motions at a sufficient rate, with possibly multiple points per frame.
This may seem costly but thanks to temporal persistence the collision detector only needs to browse through the entire collidable trees at a much lower rate and the detailed integration can be run on a small set of contacts to be monitored at a given time.
The time step itself is controlled based on the ETA for approaching shapes, the relative velocity of overlapping ones, and the stored energy of the springs. The latter point is important to maintain a high sampling rate when the string is at maximum elongation (and stored energy) while the relative velocity is then deceptively very small.

Applied forces at a contact:

• The elongated spring force is proportional to the overlap distance (tends to separate the contacting shapes).
• The damping force is proportional to the relative velocity along the contact normal and is adjusted for over-damping to model inelastic contacts (that is most of the impact energy is transferred to the structures and the bouncing is limited). It tends to oppose the response from the spring.
• A simplified sliding friction force opposes the relative tangential velocity at the contact point, with a magnitude that is proportional to the spring force.

High-velocity impacts

There are no artificial limits on velocities in the game and as a result the system must deal with possibly very high relative velocities and energies at impacts. This poses two problems:

• Detection failure: when sampling at the animation frame rate (typically every 16 ms or so at 60 FPS) the system may fail to detect overlaps for small shapes moving by comparatively much larger distances than their sizes between subsequent frames.
• Simulation crash: when unrealistically large impact forces and moments lead to undefined or inconsistent out-of-range numbers in the integration results.

Detection failure is dealt with by the time step control method. The integration sampling rate is increased both for currently occurring contacts but also preemptively for imminent ones. Similarly it may reduce the time acceleration as needed (down to x1 = real time).

The robustness of the simulation is obtained thanks to a limitation of the linear and angular accelerations. In effect rigid-body physics is not maintained anymore because the collision response forces just cannot counteract the impact initial relative velocity in time, and the shapes may as a result go through each other. However the simulator remains operational and thus can detect destructive amounts of energy leading to a “game over” situation. Also this makes sense since the ship is not a “rigid-body” anymore after being vaporized by an impact!

The next work item is about making docking ports operational at stations,

Thanks for reading!