Feedback Double-checking if this is an accurate display of a problem with explicit euler

(This isn't directly related to Unity-specific physics but this is related to another thread I started almost a year and a half ago. Apologies if this is too off-topic, however)

Back in Jan 2021 I created a thread asking for help solving an issue with a character not reaching the correct jump height while using kinematic equation movement. I received lots of good info and help and was linked to this Gaffer On Games article.

I'll admit I haven't made it too far in the article for various reasons, one of them being I got stuck trying to create the closed-form solution code for the damped harmonic oscillator code in the section "Why explicit euler is not (always) so great". (I got help from Reddit eventually though.)

Basically I'm just double-checking that what I've made here is the behavior explained in that section of the article, where "Instead of damping and converging on the origin, (the mass) gains energy over time!". I'm pretty darn sure it is, but I figured, what the heck, I'll double-check it with smarter folks.



I've got the movement using numerical integration + explicit euler on the left and closed-form solution on the right. The explicit euler / numerically integrated object is gaining energy over time, while closed form solution object is damping and converging on the origin, right? (seems like a dumb question but again I wanted to double check with smarter folks)

numerical integration: F = -kx - c(dx/dt)
closed-form solution: f(t)=e^{-At}sin(Bt+C)

code here: https://www.toptal.com/developers/hastebin/ivarihamuz.csharp

Thanks!

 

Explicit euler can gain energy over time, and it seems like this is indeed what you have here.

You're chopping up time into dt-sized timesteps, and you're using a linearized approximation of things: velocity cannot change direction or magnitude within a timestep. So if your dt is large enough, an object that needs to decelerate during a timestep will end up further that it should have because it is unable to "hit the brakes" until the next timestep: your integration scheme will overshoot.

Next timestep, the corrective force applied will be larger since the object is not where it is supposed to be. The change in position due to the new velocity will be overestimated again, which will cause the corrective force to be even larger next timestep... and things will only get worse from there on.

This is in a nutshell the reason why velocity-based simulations can become unstable/explode if the timestep is too large. Solutions? use a smaller timestep or a more accurate integrator. More hacky solutions like clamping max velocity magnitudes are not unheard of in games.

PBD (position-based dynamics) circumvents this problem entirely by calculating corrective positional deltas instead of forces/accelerations, and deriving velocities from positions. Some constraints cannot easily be expressed as positional corrections, though, and it is very dissipative (instead of gaining energy, it usually loses it) so it has its limitations. Verlet integration is closely related to it too.

 

Belated but thank you a bunch for the detailed response