Physics Simulation Forum

Pseudo-necro'ing this thread for an update on my progress.

I started to dive into the maw of madness that is the internals of bullet. I initially looked at the actual code related disabling collisions between objects. The code there was surprisingly simple and isolated. Long story short is that I ruled out some kind of actual collision occurring between the objects, that was working as intended. So instead I decided to look at the constraint solver. On a hunch I thought maybe the existing Manifolds for the collision was causing some kind of stability problem for the constraint, so I added code to remove the Manifold before the constraint is constructed and added to the world. This substantially improved the stability of the constraint, but didn't fix the issue entirely. After doing a ton a run-time tests the constraint seems to be most unstable when the object penetrates by more then a slight bit (I'd estimate ~1 unit to be the threshold).

I'm still doing tests to try and figure out I can weed out the last bit of instability...but if anyone has an explanation as to why pre-existing Manifolds would cause a constraint to be unstable or why penetration depth would matter in this case, I'd love to hear it.

Just a brief observation here without having looked at any of your code..

but disabling collisions between two already interpenetrating bodies, is this really a well-tested scenario?

What I mean is, there might be tons of state variables and caches inside Bullet that could cause trouble.

I've looked at lots of code inside Bullet and while it is a great work in total, it IS undocumented to 95% and contains a LOT of special cases with a lot of hacks. As usual in complex code, cases that are not tested all the time can and will rot.

If I was in your shoes I would do this:

1) reduce all objects to a BARE MINIMUM, this includes removing all but one of the trays, and removing all sub-shapes in the compounds except one box (for example)

2) when you want to "glue" your objects together, don't do it that way - remove/delete the green blob, then recreate an identical blob in the same position and add it to the world with a constraint that disables the object collisions. Same that you do now but with a new object, and this case is known to work.

Regards

I'd like to know if you ever solved this. My test still demonstrates the same behavior as of today.

I never got it completely working and had to move on to other features, so this one got shelved. I'm probably going to come back to it soon after I finish a few other tasks. The last thing I did was add code to clean not only the manifolds as I mentioned in my previous post, but also all the broadphase pairs. Essentially I duplicated the logic for removing the object from the world, but not actually remove it from the world/destroy it's proxy. This also added a little bit of stability, but still not enough. Occasionally I get the wrong offset, or it attaches to the wrong object(no idea how that works), and rarely it still generates forces it shouldn't.

The last thing I can think of to try when I get back to it is as MonkeyMan suggested...serializing the object, destroying it, and then re-creating it with the constraint.

Bullet 2.80 has some new demos that fix rigid bodies on-the-fly using a 6dof constraint. Check out Bullet/Demos/VoronoiFractureDemo and Bullet/Demos/SerializeDemo.

In a nutshell, you have to remove and re-insert the rigid bodies to the dynamics world. This is a workaround to flush the old contact points/manifolds.

In addition, you can now increase the number of solver iterations for individual constraints (it doesn't affect other objects/constraints).
Thanks,
Erwin

Thanks erwin for commenting. I have updated my version to 2.80 and attempted the things you suggested. Neither had any effect.

I was already cleaning the manifolds and broadphase pairs before I tried to remove and re-add the object to the world. I got the idea from looking at the actual "removeRigidBody", so it doesn't surprise me that changing that had no effect.

I also tried setting the number of iterations for the constraint to 100 as well (10 is the global default if I recall). This actually seemed to make the simulation less stable. I saw more occurances of extra forces being generated then I did before. Although I can't say for certain if that is because of the upgrade, the setting, or something else. I will say that at the suggestion of some others I am using the btSliderConstraint currently for my sticky behavior. When I get a little more time I'll switch it back to the btGeneric6dofConstraint and post the results.

Can you please check out Bullet/Demos/VoronoiFractureDemo in Bullet 2.80 and see if that works for you?

Then compare it with your implementation, and see what the differences are.

If you figure out what went wrong, can you please report it here, so others can learn from it?
Thanks a lot,
Erwin