Page 1 of 1

XPBD rigid-body simulation with hard penetration constraints

Posted: Tue Dec 07, 2021 8:49 am
by jhelsing

I'm trying to implement a XPBD rigid-body simulation by following this paper: ... Bodies.pdf

So far, I've got down the basics of the algorithm and added support for circle and rectangle contact constraints.

It works well in the general case, but when I try stacking more than a few bodies on top of each other and crank up the number of sub-steps to something like 10, the bodies start bouncing out of control.

If I make the penetration constraints barely compliant (like 0.001), it goes away, and if I disable sub-stepping, it works. However, in the paper, they say they're using a compliance of 0 for penetration constraints and they're using sub-stepping, so I'm wondering what I'm doing wrong...

Short video of the weird bouncing:

Any ideas?

Re: XPBD rigid-body simulation with hard penetration constraints

Posted: Tue Dec 07, 2021 10:30 pm
by jak
Hard to say from just the video, so this probably won't be accurate, but maybe it'll still help in a rubber-ducking kind of way.

The first thing it makes me think is that somewhere in your velocity/restitution code you're using full Δt instead of the substep Δt. You could try turning off restitution to see if you can make more stable stacks (that will have bounce out problems when contact ends, but at least shouldn't explode). If that works, that's a very good sign the restitution is somehow messed up, whether a Δt problem or something else.

Re: XPBD rigid-body simulation with hard penetration constraints

Posted: Tue Jan 11, 2022 4:01 pm
by jhelsing
Thanks for the tip, Jak.

I did figure it out in the end, and it turned out to be just a stupid mistake on my part. I'd sort of cheated and recomputed collision pairs in the velocity solve, but it meant that sometimes I missed a velocity solve, and sometimes I took one when I shouldn't. Now I'm simply storing every colliding pair and iterating over the exact same pairs.

I got a bit further since last time, and I've added boxes, rotation and friction against static objects... and then I ran into another kind of jitter bug.

Objects kind of don't want to stay on the ground, and "tip" to one side or the other.

I tried implementing the "jitter prevention" mentioned in Matthias' paper (skip restitution if the normal velocity is below a certain threshold), but it seemed to only make matters worse, which is kind of weird.

Progress so far: ... index.html

Re: XPBD rigid-body simulation with hard penetration constraints

Posted: Wed Jan 12, 2022 6:38 am
by jak
Nice demo. Always nice to be able to just click a link and see something running in the browser.

I reckon you'll figure it out if you just keep at it. Again, bugs like this could be a million different things, so it would be hard to diagnose remotely. But because apparently I like making random uniformed guesses, I will go ahead and say what your bug description made me think of. Traditionally with 2D box collisions like you're doing, you'd calculate 2 contact points and base the collision response off the pair. Implemented properly, that should be stable and shouldn't allow tipping. I feel like I read somewhere (probably just the original paper) that people were having success with small step XPBD just using a single contact point, but in that case you need to be sure you're always pushing out from the point of deepest interpenetration. If you just use one contact point and somehow cache it, you'll essentially create a hinge that will let your box tip into the ground, and of course as soon as the collision gets recalculated properly, the box will be highly interpenetrated and will jitter or even go rocketing out.

Re: XPBD rigid-body simulation with hard penetration constraints

Posted: Fri Jan 14, 2022 4:53 pm
by felipekersting
hey jhelsing,

what a coincidence, I also recently implemented this paper! This is the state of my engine atm:

if you are interested, send me a message and we can probably help each other with these problems. I'm currently implementing joints.