[Solved] RagDolls penetrating static TriangleMeshShapes

[VicariousEnt]

Looking for a little help for a good solution with this problem in our game. It looks to me like a flaw in the way Bullet handles collision on constrained objects but could be a small object problem.

Basically we have a complex rag doll setup for our main character, built entirley from btCapsuleShapes the exact same way as in the Bullet ragdoll demo. Our world is made up of OptimizedBVHs (exported from Maya as static Meshes, so formerly GIimpact meshes but the change to BVHs didn't affect this problem). We move the character around with Point2Point constraints attached to parts of the body. The problem manifists itself when a hand is attached to the world geo (with a p2p constraint). If the torso of the character is moved around with another p2p so that it presses against the hand or forearm capsule, it appears that the collision response between the torso and hand capsules cleanly pushes the hand (or forearm) through the world geo. And then the hand and\or forearm is permantly stuck inside the world. I've turned on the ContiniousCollsionDetection and tuned it to elimante all cases of individual body parts from penetrating through the world on large falls, but it doesn't help with this issue no matter what I set for swept volume and motion threshold.

The hand has a radius of .035 and length of .09 (all in meters), and the forearm is 0.045 and 0.2. I've tried pushing the hand radius up to a portly .07 and it didn't change anything.

I've stepped into bullet and the hand capsule to OptimizedBVH collision pair is resolved first everytime and properly, it just appears that the collision response from the torso to hand collision supercedes that result. Is this a hole in the collision resolution logic in Bullet or should I be doing something differently to handle this scenario?

We are running Bullet 2.78 (problem existed in 2.77 as well) and I've tried adopting the change in 2.79 that comments out the SpeculativeContacts to no avail. I've tried running native 2.78 and with my own fix for issue 356 (http://code.google.com/p/bullet/issues/detail?id=356) to no avail.

For the time being I've got a decent work around of using the CollisionFilterMasks to exclude collsions between the hands\forearms and torso but this problem still occures occasionally in falls and such when other body parts press against the hands or feet. I'll have to try and detect when limbs are pushed through the world geo and pop them back out if Bullet can't reliably prevent this from happening. Development time wise we could still adopt another release of Bullet before shipping.

Thank you for your time.

[VicariousEnt]

Coles notes version (I write too much), with pictures to explain the problem..



World is an Optimized BVH. Character is built on the Bullet Ragdoll demo with btCapsule shapes. A Generic6Dof constraint attaches the hand to the world geo. A Point2Point constraint is moving the torso capsule on the rag doll, pushing it against the hand capsule. As the two capsules collide with each other, the hand is effortlessly pushed through the world geo. The torso does not penetrate through and neither does the hand when its not being pushed by another capsule in the rag doll. Any ideas or solutions would be very much appreciated.

Would love to have the CCD system fixed too. I'm Running with the 2nd portion of it commented out to fix another problem with rag dolls falling at high speed. This work-around allows the odd piece of the ragdoll through occasionally on big falls (no, this work around doesn't affect the main problem).

[VicariousEnt]

I should also note that if the character in above scenario is hanging from one hand thats constrained to slightly upwards tilted world geo, and falls hard enough, the hand and occasionally forearm will sometimes be pulled through the BVH. Low framerate and or a alot of downward velocity on the body can make this happen more often. Framerate does not affect the original problem however.

The CCD system seems to work alright (pre 2.79 anyways) for individual RBs, but ones that are constrained to each other have alot of problems with the CCD system. I could modify one of the bullet samples to reliably expose these problems if necesary.

[VicariousEnt]

Fixed! Erwin gave me a suggestion which led to the solution. In short, stepSimulation was hitting the maxSubSteps limit. I wouldn't recomend anyone use maxSubSteps to limit how many times Bullet updates in a single frame if you're using the CCD system. Instead pick a reasonable fixed time step to control how many times Bullet iterates in a single frame (60hrz is the default and is quite reasonable).

I cranked the maxSubSteps limit and put an error message in to complain if the number of interations returned from stepSimulation ever hits the limit again. Problem solved!