Improving collision detection/response for rag dolls

Post Reply
User avatar
Octavius_Ace
Posts: 20
Joined: Sat Jun 04, 2016 10:34 pm
Location: Edinburgh

Improving collision detection/response for rag dolls

Post by Octavius_Ace »

Hi,
I have skeletal mesh animation and the transition to bullet-controlled rag doll animation working and now want to improve the collision detection/response between the rag doll's rigid bodies and the static world mesh.

For simple test purposes, I have a chain of 3 rigid body capsules, with 2 ball-joint constraints connecting them.
My world mesh consists of a btBvhTriangleMeshShape and it is very common for applied impulses to push and trap the ragdoll's capsules on the "underside" of the mesh landscape.

Are there any general configuration pointers that will allow me to improve this collision interaction?

I've searched the forum and came up with the following similar query:
[Solved] RagDolls penetrating static TriangleMeshShapes
This suggests increasing the maximum number of sub-steps for each simulation step to improve matters. I'm currently using maxSubSteps=10, with the default fixedTimeStep = 1/60th
As increasing the number of sub-step iterations has a performance implication, I also want to explore any other config changes that may improve matters.

So any advice will be much appreciated.

Thanks.
StabInTheDark
Posts: 29
Joined: Sat May 18, 2013 1:36 am
Location: NY
Contact:

Re: Improving collision detection/response for rag dolls

Post by StabInTheDark »

First make sure your physics world is scaled correctly.
Objects below a certain size will easily fall thru.
You need to implement constant collision detection.

I had no problems after I used these solutions.

https://www.youtube.com/watch?v=y1B6OzYVJGo
User avatar
Octavius_Ace
Posts: 20
Joined: Sat Jun 04, 2016 10:34 pm
Location: Edinburgh

Re: Improving collision detection/response for rag dolls

Post by Octavius_Ace »

Thanks for taking the time to reply. It's much appreciated.

The scaling advice is a good pointer, although my rigid bodies are around the 0.5 to 2 unit size, which I believe conforms to the "good practice" pointers found in the bullet manual. That said, my test landscape mesh does have comparitively large triangles, so that could be an issue - I'll experiment a little.

What has helped somewhat, is adding constraints with the "disable collision detection" flag set and controlling interpenetration with angular limits. This reduces the problem to an extent.

I'll try the continuous collision detection and see if that helps without too much of a performance hit and report back with results.

Cheers.
User avatar
Octavius_Ace
Posts: 20
Joined: Sat Jun 04, 2016 10:34 pm
Location: Edinburgh

Re: Improving collision detection/response for rag dolls

Post by Octavius_Ace »

For anyone who is interested, implementing per rigid body CCD, has not improved the interpenetration issues I'm experiencing.

I have set up CCD on each of the RBs in a 3 RB/2 hinge constraint chain, so RB + hinge + RB + hinge + RB.
Each RB has a capsule as its collision shape.
I have also set the swept sphere and motion threshold as follows:

Code: Select all

	pBody->setCcdSweptSphereRadius( localExtents.m_floats[ localExtents.minAxis() ] * 0.5f );
	pBody->setCcdMotionThreshold( 0.0001f );
So this gives a very small motion threshold and sets the sphere radius to half the smallest RB bounding box extent.
Unfortunately, this has produced no visible difference to the capsule/static BVH triangle mesh interpenetration.
Using different values for the swept sphere radius, e.g. minimum capsule extent x 1.0f, 0.2f or 0.01f, produces no improvement.

There's a video of the behaviour at:
https://www.youtube.com/watch?v=hft6FcH6sUQ
for anyone who is interested.

So if anyone has advice on where to look next, I'd be most appreciative.

Cheers.
erbisme4@yahoo.com
Posts: 41
Joined: Fri Apr 29, 2016 2:41 pm

Re: Improving collision detection/response for rag dolls

Post by erbisme4@yahoo.com »

how did you implement ccd per object?
User avatar
Octavius_Ace
Posts: 20
Joined: Sat Jun 04, 2016 10:34 pm
Location: Edinburgh

Re: Improving collision detection/response for rag dolls

Post by Octavius_Ace »

Long time since your question re. Setting up CCD but just in case you check back:
I set up CCD as per the user manual, i.e. just call the 2 functions detailed above on a specific rigid body instance.
As far as I'm aware that's all that is required.

For anyone who's interested, I never resolved this issue, just living with it and moved on to other things.

Interestingly, I came across a chap with a game engine suffering the same problem and the only way he got round these issues was to use convex hulls as static terrain geometry instead of a BVH tri mesh.

As ever, if anyone has has bright ideas on root cause or mitigation strategies, do let me know.

Cheers.
User avatar
Octavius_Ace
Posts: 20
Joined: Sat Jun 04, 2016 10:34 pm
Location: Edinburgh

Re: Improving collision detection/response for rag dolls

Post by Octavius_Ace »

I finally managed to fully resolve the issues described above and collision response between chains of constrained bodies, including rag dolls and BVH Tri-meshes are now error-free.

The solution was two-fold, with the first step being embarrassingly obvious:
1) I was using v2.82 rather than the latest v2.87 of the framework. Having browsed the fixes applied in GitHub, I noticed that work was done on tri-meshes a couple of years ago, so I updated the 3 bullet folders I use in my code: BulletCollision; BulletDynamics and LinearMath(s) to v2.87
This had an amazing impact and corrected virtually all triangle collision issues.

2) For rag dolls with several chains of constraints, I was still seeing collision shapes trapped behind triangles. This led to the second part of the solution, which came from a post response by "lunkhound" to a similar issue:
https://pybullet.org/Bullet/phpBB3/view ... =9&t=10224
His code snippet and response made sense to me, so I dropped it into my project and hey presto! Collision response is rock solid now. (So thanks for that.)

To recap lunkhound's solution:
Bullet doesn't appear to (consistently) treat triangles as being front / back-facing. So it sometimes generates contact normals that point "behind" the triangle. The solution is to check that the contact normal points in the same direction as the front-face of the triangle (for collisions pairs involving at least one triangle shape). This is an easy check to make:
1) Assume anti-clockwise triangle vertex winding and derive the front face normal using two triangle edge vectors and a cross-product
2) Transform the triangle normal to world space (if required)
3) Perform a scalar product (a.k.a dot product) between the world space triangle normal and the contact normal. This gives the projection of one vector onto another.
4) If the result is less than zero, the contact normal is facing in the opposite direction to the triangle normal, so update the contact normal by reflecting it in the triangle plane.

A couple of optimisations are possible with the normal check/reflect code:
1) If memory isn't an issue, the triangle structure/class can be enhanced to store a pre-computed face normal
2) If you're only concerned with static tri-meshes, ensure vertices are already in world space and the transform into world space becomes redundant.

I've recreated my original test case on youtube, to demonstrate the fix.
https://youtu.be/LAfF90g3T4g
Post Reply