Hey! Congrats on the launch, the touted performance increases are mind blowing.
I think physics engines are difficult for a few reasons:
- They don't mesh with a lot of features that modelers take for granted (non-uniform scaling, concave meshes, lax model scaling)
- It's hard know intuitively what values to use for things like acceleration, density, velocity, damping, friction. Especially because they are very inter-dependent.
- Interaction with moving kinematic or non-physics objects is an undefined behavior that has to be tested pretty rigorously.
- In gamedev, rigidbody physics are basically a trojan horse for gameplay bugs like clipping through the map and sudden bursts of high speeds (Which is both magical and frustrating). It's a non-trivial task to sandbox those behaviors completely.
- Projectiles. There's no catch-all solution for small fast-moving objects, it's always a tradeoff. But that's mostly because big O dictates it to be so.
Verlet physics are so nifty. A basic implementation with points, springs, gravity, and a simple floor (a Math.max check) produces stunning motion. Going from trying to tune angular momentum calculations to getting believable rotation 'for free' felt like a revelation
All those are great physics engines. Mine is just very simple and easy to understand, hopefully it inspires other people to get into the world of simulations.
It's nice that they've actually demonstrated something in it. The differential physics engine is pretty freaking cool. Also, if you look at some of the details they talk about it's clear that just having a differentiable language isn't enough: it's still very easy to have gradients which don't work properly if you're not careful, especially in boundary conditions (the example they give is collision detection).
Making a 2d rigid-body physics engine is a really fun project. I made one myself in javascript before learning about linear algebra. And I dug deep into the maths to get it working. Despite months of work, I barely scratched the surface beyond the widely known basics.
Making a stable engine where objects don't compress into one another or jitter is a rabbit hole without a bottom that even the most math-heavy articles I could find rarely touched.
To give some context, this is only part one in a series of blog posts I plan on writing about rigid body physics.
The post is aimed at people like myself, who aren't game devs and don't necessarily have a strong math background. Which is why I spend so much time explaining concepts that would appear almost trivial to someone who has experience in this area.
Sounds intriguing! I’m probably your ideal audience, given a large coding background, low math background, and current writing 2D focused games.
If I may ask a question, in your mind what’s the benefit of more deeply understanding these implementations when physics frameworks handle a lot of the really mathy logic behind collisions and simulations.
Either way I’m putting this in my read queue. Thanks!
I'm especially impressed by the time scaling. Back when I fiddled around with physics collision/physics libraries years ago (ODE), have a fixed timestep was a fundamental design decision and changing that led to weird and unpredictable behaviour.
Things have come quite a long way :)
Edit: still has problems with squishiness of stacked solid objects though :\
reply