The article says that Euler integration is commonly used in games, and I'm not sure that's true; it's been popularised in gamedev since many years that, and I quote, "if you use Euler integration, then you're a bloody idiot"[0].
BTW the same article series points out that using irregular timesteps is also a bad idea.
Most gamedevs haven't really researched numerical integration, they've just heard that the naive method, which is very often hand rolled outside of physics engines, is Euler; and that particle simulations should use Verlet because reasons. (The inner reason being that the first Hitman game used Verlet and they published a paper about it.)
The most common integration method in physics engines for games is semi-implicit Euler, which the article is implying from the source code. I think you are confused with explicit (forward) Euler, which nobody really uses.
For those not in the know (I had to double-check myself), the difference between explicit and semi-implicit Euler is simply the order in which position and velocity are updated.
Misc comment but I find it odd that the author seemingly intentionally killed those old posts, you couldn't google "game physics" a decade ago and not see his timestep post which helped a lot. Glad I run my own archiver.
Writing that programmers that use Euler instead of RK4 are "bloddy idiots" might work well to get some laughs in a blog post when the author is trying to stress how RK4 is more accurate and stable than the alternative, but there are cases where real-time applications (especially on older machines and older consoles) could not afford the overhead of RK4 and Euler was gave good-enough for what they needed.
Forward Euler is very terrible and can give you wildly wrong answers after just a few steps. If you think higher Runge-Kutta and fancy methods are too complex/expensive you do have cheap and stable options, like implicit euler or leapfrog. It's very likely that your numeric integrator is going to be a hot part of your game loop, it's worth doing ten minutes of research, IMHO.
Leapfrog is so easy to implement, as well. It might require a smaller timestep than some fancy techniques but it is very cheap per timestep. And given that it is accurate enough for statistical Physics simulations, so about 2 orders of magnitude more accurate than it needs to be for a game.
Using irregular timesteps _might_ not be a bad idea if you know what you are doing (but probably not for the usual kinematic simulations). See Dynamic Monte Carlo, Gillespie algorithm, First Reaction method etc (these are mostly the same thing).
The article says that Euler integration is commonly used in games, and I'm not sure that's true; it's been popularised in gamedev since many years that, and I quote, "if you use Euler integration, then you're a bloody idiot"[0].
BTW the same article series points out that using irregular timesteps is also a bad idea.
[0] Since gone offline, and without the famous quote, but there's an archived copy here: https://vodacek.zvb.cz/archiv/680.html
Most gamedevs haven't really researched numerical integration, they've just heard that the naive method, which is very often hand rolled outside of physics engines, is Euler; and that particle simulations should use Verlet because reasons. (The inner reason being that the first Hitman game used Verlet and they published a paper about it.)
> The inner reason being that the first Hitman game used Verlet and they published a paper about it.
Here's[1] the paper for those who are interested.
[1]: https://www.cs.cmu.edu/afs/cs/academic/class/15462-s13/www/l...
The most common integration method in physics engines for games is semi-implicit Euler, which the article is implying from the source code. I think you are confused with explicit (forward) Euler, which nobody really uses.
For those not in the know (I had to double-check myself), the difference between explicit and semi-implicit Euler is simply the order in which position and velocity are updated.
Explicit updates position with the old velocity:
Semi-implicit (symplectic) with the new velocity:Misc comment but I find it odd that the author seemingly intentionally killed those old posts, you couldn't google "game physics" a decade ago and not see his timestep post which helped a lot. Glad I run my own archiver.
Writing that programmers that use Euler instead of RK4 are "bloddy idiots" might work well to get some laughs in a blog post when the author is trying to stress how RK4 is more accurate and stable than the alternative, but there are cases where real-time applications (especially on older machines and older consoles) could not afford the overhead of RK4 and Euler was gave good-enough for what they needed.
Forward Euler is very terrible and can give you wildly wrong answers after just a few steps. If you think higher Runge-Kutta and fancy methods are too complex/expensive you do have cheap and stable options, like implicit euler or leapfrog. It's very likely that your numeric integrator is going to be a hot part of your game loop, it's worth doing ten minutes of research, IMHO.
> like implicit euler or leapfrog
Leapfrog is so easy to implement, as well. It might require a smaller timestep than some fancy techniques but it is very cheap per timestep. And given that it is accurate enough for statistical Physics simulations, so about 2 orders of magnitude more accurate than it needs to be for a game.
Symplectic Euler is often a good compromise. It's as simple as forward Euler but has better energy conservation.
Using irregular timesteps _might_ not be a bad idea if you know what you are doing (but probably not for the usual kinematic simulations). See Dynamic Monte Carlo, Gillespie algorithm, First Reaction method etc (these are mostly the same thing).
(2022)