Thorough scrutiny of the performance of our physics engine is paramount for the game to run smoothly seeing as the physics update is the most important and - if there are many entities - expensive part of the game loop.
In contrast to the terrain generation, this part can only be parallelized with great effort, which is why we attempted to increase performance of the sequential execution of physics updates between frames.
Our physics engine can simulate a heap of up to 50 rocks (a heap is the worst case scenario as rocks are constantly colliding).
With the right configuration of the physics engine, the simulation can be pushed to up to 100 rocks, however, some visual accuracy and smoothness is lost.
The crucial parameters for the performance of the physics engine are $\delta t$ and the maximum number of physics steps added to the accumulator per frame.
The latter presents a solution for the `spiral of death`.
This phenomenon occurs when the physics engine takes more time to consume the time in the accumulator than the time currently in the accumulator.
In that case, more time is added to the accumulator than in the previous step, effectively dropping the frame rate to zero after a while.
By limiting the maximum number of physics steps that are added to the accumulator per frame ($spf$), this effect can be mitigated to a certain degree.
The figure below shows the effects of these parameters on a compute-heavy simulation with many rocks.
Interestingly, the choice of $\delta t$ has only a minor effect on performance.
A larger $\delta t$ leaves more room for the physics engine update step and thus the $fps$ drop a bit later.
However, the choice of the $spf$ seems far more important.
Using an $spf>2$ we always run into a spiral of death during the simulation.
In the actual game however, we even use $spf=10$ (and $\delta t=0.015s$).
This is because in a real game, the number of rocks is much smaller, so performance is not an issue.
The choice of a bigger $spf$ yields visually smoother and more accurate results.
Although the effect of $spf$ on $fps$ is obvious, we can only speculate why $spf$ has an impact on the time needed for a physics update.
We assume that this effect stems from stack management overhead when more steps are performed per frame.
Figure: Time needed for a physics update (left) and frame rate (right) over the course of a simulation dropping 100 rocks into a bowl in the first 30s. The physics update times are approximated via regression using polynomials of degree 6 and a 95% confidence bound is plotted. For $spf=4$, we run into the spiral of death.
In conclusion, although it is not arbitrary scalable, we deem the performance of the physics engine sufficient for the purpose of our game.
Using efficient garbage collection when entities and terrain leave the scope of the game in combination with adequate performance allows the game to always run steadily.