Unstable collisions

[johanhelsing]

You mentioned in #1 that you were struggling with "unstable collisions", and this was something you'd like to fix before releasing. Just though it might be useful to have an issue for it.

Maybe explaining it and having some extra eyes on it would help :)

(fwiw I was also having trouble with unstable things as I added friction in the tutorial series), and I never quite figured it out, perhaps this is the same thing?

[Jondolf]

Hi, I've been looking into this for like seven hours straight and have kinda fixed the problem, or at least the worst part of it. The main problem seems to have been caused by 3bbc15f, or the narrow phase to be precise, which should now be fixed, although maybe not ideally.

Collisions are generally stable again, but there's still some jitter and occasional (much rarer than before) "pops" or "explosions" where bodies randomly gain huge velocity. I believe this might be caused by some completely different problem(s) than the one I fixed, but we'll have to look into it a bit more.

I'll try to elaborate further when I have time (hopefully tomorrow) and share my findings in more detail.

[Jondolf]

I still haven't found the exact problem or any good fixes, but I'll show what I've found so far in case anyone else wants to take a look at this.

One problem seems to be related to the sizes of AABBs. I have this system that updates AABBs at the start of each iteration of the simulation loop (only on the first substep), and I expand the boxes by a distance of $k\Delta t v_{body}$, like Matthias Müller's XPBD paper suggests:

fn update_aabb(mut bodies: Query<(ColliderQuery, &Pos, &Rot, Option<&LinVel>), AABBChanged>) {
    // Safety margin multiplier bigger than DELTA_TIME to account for sudden accelerations
    let safety_margin_factor = 2.0 * DELTA_TIME;

    for (mut collider, pos, rot, lin_vel) in &mut bodies {
        // -- shortened --
        let scaled_half_extents = half_extents + safety_margin_factor * lin_vel.length();
        collider.aabb.mins.coords = (pos.0 - scaled_half_extents).into();
        collider.aabb.maxs.coords = (pos.0 + scaled_half_extents).into();
    }
}

However, this doesn't seem to be enough, as the simulation is very unstable:

cubestack_unstable.mp4

If I make the AABB even larger by multiplying the half extents by two with let scaled_half_extents = (half_extents + safety_margin_factor * lin_vel.length()) * 2.0; , we get a much more stable result, but this will obviously be very bad for performance.

cubestack_more_stable.mp4

So there's something wrong with the way AABBs are handled and/or updated.

You can also see the boxes jittering and drifting slightly, even with expanded AABBs, so this isn't the only issue. I think rotation and angular velocity could be causing this in some way, because commenting out rotation stuff from the penetration constraints and the velocity solver eliminated jittering completely. Removing friction didn't seem to do anything according to my testing, but the issue could of course be a combination of things.

I will keep looking for a fix when I have time, although this is a pretty annoying bug to track down 😅 I would ideally like to get this fixed before I add new features or other improvements, or even update to bevy 0.10, to make sure I don't break things further.

If anyone finds a fix, let me know :)

[Jondolf]

Update: The AABB sizing issue should now be fixed by 12e5b9a. This eliminates the large "explosions" where bodies sometimes gain huge velocity on collision.

The drifting/jittering issue still exists, and it seems to be unrelated to AABBs. Bodies sometimes slowly slide and/or rotate along the ground, even doing small occasional jumps. I still don't know what causes this, it could be related to friction, rotation, incorrect contact positions etc.

[Aceeri]

Looking into this more deeply and found some things:

It seems like the Collision::{world_r1, world_r2} contact points oscillate between the extremes of the cubes in the cubes example:

2023-06-02T02:06:24.425028Z  INFO bevy_xpbd_3d::steps::solver: entity1: "4v0", contact DVec3(-0.207, 0.500, -0.180)
2023-06-02T02:06:24.425037Z  INFO bevy_xpbd_3d::steps::solver: entity2: "Cube 0 0 0", contact DVec3(1.000, -1.000, 1.000)
2023-06-02T02:06:24.425096Z  INFO bevy_xpbd_3d::steps::solver: entity1: "4v0", contact DVec3(-2.207, 0.500, -2.180)
2023-06-02T02:06:24.425102Z  INFO bevy_xpbd_3d::steps::solver: entity2: "Cube 0 0 0", contact DVec3(-1.000, -1.000, -1.000)
2023-06-02T02:06:24.425159Z  INFO bevy_xpbd_3d::steps::solver: entity1: "4v0", contact DVec3(-0.207, 0.500, -0.180)
2023-06-02T02:06:24.425165Z  INFO bevy_xpbd_3d::steps::solver: entity2: "Cube 0 0 0", contact DVec3(1.000, -1.000, 1.000)
2023-06-02T02:06:24.425233Z  INFO bevy_xpbd_3d::steps::solver: entity1: "4v0", contact DVec3(-2.207, 0.500, -2.180)
2023-06-02T02:06:24.425238Z  INFO bevy_xpbd_3d::steps::solver: entity2: "Cube 0 0 0", contact DVec3(-1.000, -1.000, -1.000)
2023-06-02T02:06:24.425309Z  INFO bevy_xpbd_3d::steps::solver: entity1: "4v0", contact DVec3(-0.207, 0.500, -0.180)
2023-06-02T02:06:24.425316Z  INFO bevy_xpbd_3d::steps::solver: entity2: "Cube 0 0 0", contact DVec3(1.000, -1.000, 1.000)

I think this means that the cubes are essentially wobbling back and forth for a while? When you isolate the cubes to just a couple, it seems like they only rotate infinitely which leads me to believe something about the angular velocity delta is off.

Friction/restitution for angular velocity seems to work fine (at least at a first glance) otherwise I'd expect if I increase the spinning of a cube it should stay at that velocity but it does go back down to a more constant smaller one.

[Jondolf]

Update: The drifting and explosions have been mitigated pretty much entirely by #90, and numerical stability was also improved by #84, although that mostly helps with far-from-origin situations and high masses.

However, for non-convex colliders like trimesh colliders, the problem still persists due to issues I had while trying to use contact manifolds for them (see #93), so I'll still keep this issue open until that has been resolved. For many cases though, collisions should already be very stable.

[Jondolf]

Pretty much all remaining collision stability issues were fixed by #156, so I finally closed this issue :) I don't think the problems described in this issue are relevant anymore, so for any future collision problems, it's probably best to open new issues.

Convex hulls still have some problems in specific situations when the faces are large, but this seems to be an issue in Parry rather than bevy_xpbd. I opened an issue for this here: dimforge/parry#166