31–40 of 69 posts
Like those old atari games where everything was little square tiles / pixels.
But little squares aren't the most expressive geometry.
How about kisrhombille?
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.
I used a series of old articles by Christ Hecker to understand the maths myself. http://www.chrishecker.com/Rigid_Body_Dynamics
The way this article is written with small simulations throughout the page and word highlights was reminding me of https://ciechanow.ski/ and then I noticed the domain name. It is very similar too https://www.sassnow.ski/ Couldn't be happier seeing more people going to same depths (or heights) to explain things to people. Will be looking forward to more articles like this as this just the very first one.
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…
Hey everyone, author here! 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. Happy to answer any questions you…
Are you planning to read/explain through XPBD (Extended Position Based Dynamics - http://mmacklin.com/xpbd.pdf) as well in future posts? The concept seems to be gaining traction and I've used it with Bevy (via https://github.com/Jondolf/bevy_xpbd) with big success so far, seems more stable than the usual approach.
One side project I am working on right now is a 2d space shooter I am developing with my son. The idea is to have top down look, have each player control some kind of ship and fly in an enclosed area filled with space debris and shot opponents. An important aspect of this game is that the space debris can be moved around the arena and used creatively to capture opponents, prevent them from achieving their goals, etc.…
[1]https://m.youtube.com/watch?v=lS_qeBy3aQI&pp=ygUSVmVybGV0IGl...
[2]https://m.youtube.com/watch?v=3HjO_RGIjCU&pp=ygUSdmVybGV0IGl...
You probably don’t want rigid body collisions in most game mechanics. Player controllers, npc logic, etc. are hand crafted most of the time.
Earlier quoted context omitted.
That sounds like the kind of thing which works if you're doing physics at 1kHz+ with an integration algorithm with good numeric stability which honours conservation of energy, but in games, we're often running physics at down to 30Hz using some ad-hoc Euler-Chromer, which requires very different approaches
It's still the same principle even in games. If you are trying to explain where forces come from and how resolution works, you need to ground it in something. Otherwise you are just adding extra assumptions onto assumptions.
EDIT: If I'm incorrect, please explain how. I've written some game physics systems and seen some proper physics sim systems and these comments reflect my understanding of the situation, and if I've said something wrong, please correct me instead of just downvoting.
Collisions are violations of the pairwise non-intersection constraint between bodies. Collision forces are Lagrange multipliers of these constraints. Collision normals are the (normalized) partial derivatives of the constraint function wrt one of the body's configurations.
Neat! do you have a resource that explains this perspective further?