convex hulls seem to stick together

[fastflo]

i want to use convex hull shapes for my bodies. but as soon as two of these bodies get in contact they seem to stick/glue together.
(i'm trying to simulate a robotic hand where it is not really nice when two fingers start to stick together and a considerable amount of force is required to separate them)

i've calculated simplyfied convex hulls (with qhull and gts) for mechanical parts from their CAD-data, feeding these vertices to a btConvexHullShape. i'm also trying to use real masses and inertia's.

i've attached a simple test program where i have 2 convex hull shapes in zero-gravity. at the beginning i apply a central force to the upper body (b2), pushing it towards the lower body (b1). because of that i see some contacts created and both bodies move downwards.

after some time i again apply a force to the upper body (b2) but this time in the opposite (upwards) direction -> expecting them to separate - but they dont! the stick together!
(or sometimes the trajectory of the lower body (b1) is changed by applying a force to the upper body...)

this behaviour changes depending on the exact contact situation (caused by the initial applyForce()).

i tried to create an artificial btConvexHullShape that looks like a sphere - same confusing behaviour.

if i use btShpereShape i don't have these problems.

i guess i'm having scaling-problems. my objects have not much mass and a circumference of only ~4 centimeter.

i'd really prefer not to scale my shapes and keep the physical units of mass, inertia, forces, torques.
is there anything within bullet that i can tweak/hack to keep my current units? or am i setting wrong parameter values somewhere?

but if i really have to scale, which properties need to be scaled to keep them in a sense manner?

i also tried many different time-step-combinations but the behaviour of these hull-bodies is most of the time really strange...

any hints? ideas? documentation-links?
(already spent many hours in googling, doxgen surfing, testing program...)

[Erwin Coumans]

You seem to be hitting some collision detection issue with convex hull shapes, probably due to the small object sizes/margins.
If you enable the separating axis test (SAT), by generating polyhedral features for each btConvexHullShape, it works better.

To do this, add the following line after adding all points to the btConvexHullShape (see attached file)

Code: Select all

shape->initializePolyhedralFeatures();

By the way, we should investigate this collision detection issue, thanks for the repro case!
Unrelated to this, it is better to use 'world->stepSimulation(deltaTime,0) if you want to use a fixed timestep, instead of passing a variable argument as last argument.

Hope this helps,
Erwin

[fastflo]

thanks, that helps alot!

btw.: the online doxygen doc seems to be a little outdated compared to bullet-2.79.

there is no btPolyhedralConvexShape::initializePolyhedralFeatures() in
http://www.bulletphysics.com/Bullet/Bul ... ource.html

[fastflo]

hm,

the created polyhedron seems to have a problem.

if you look at the convex hull displayed in the debug_drawer you'l see it's open! (ok, this might be only an issue with the debug drawer...)

but

if i execute the same test program and rotate the upper body (b2) by -10[deg] around z it would need this missing face... and there are no collisions created until they nearly completely intersect each other and then they'll "explode".

test program attached.

phfm.png

as i said i created these convex hulls by myself - so i have all information avaliable for them, normals, vertex ordering triangle strips and so on... so i could provide much more information than just the vertices.

is there a way for me to generate this btPolyhedralConvexShape::m_polyhedron and pass it to btPolyhedralConvexShape? (maybe by deriving my own hull-shape from btConvexHullShape with its own initializePolyhedralFeatures ()?)

[fastflo]

btw, the missing face(s) are defined by 4 vertices which are coplanar.

the btConvexHullComputer::compute() outputs 2 coplanar triangles - then in btPolyhedralConvexShape::initializePolyhedralFeatures() they are detected to be coplanar and a combinedFace is constructed -- but this face is created with only 1 vertex! (added some debug output to find this) -- i guess this is an error...

yes, the problem is the comparision between different vertices of these coplanar triangles.
before calling GrahamScanConvexHull2D() an orgpoints vector is built.
when building this vector it is checked whether (vertexA - vertexB).length2() is smaller than 0.001 units and if so this vertex is ignored. i guess to remove duplicate / nearly duplicate vertices.
in my case this corresponds to the fact that 2 vertices on this plane need to be atleast sqrt(0.001) = 0.031m => 3.1cm apart to be considered as non-dups.
and for my 4 vertices orgpoints gets only one vertex - this is an error, i'd say. and the convex hull of this 1 vertex has not much in common with the original 2 triangles.

so this constant 0.001 should probably be something relative to the area of the faces in question...

i have no missing faces and no collision problems if i put all vertices in orgpoints.

and i guess this loop should check the orgIndex before calculating the length2() - because if these orgIndex'es match you know they are exactly the same...

to test this i changed this code:

Code: Select all

for (int i=0;i<orgpoints.size();i++)
{
	if ((rotatedPt-orgpoints[i]).length2()<0.001)
	{
		found=true;
		break;
	}
}

to loop to look like this:

Code: Select all

for (int i=0;i<orgpoints.size();i++) {
        if(orgpoints[i].m_orgIndex == orgIndex || (rotatedPt-orgpoints[i]).length() < 0.0001) {
                found = true;
                break;
        }
}

(it's still an arbitrary constant 0.1mm for me -- currently i have no good idea how to improve this...)

i've added a ticket to the issue tracker http://code.google.com/p/bullet/issues/detail?id=555

[Erwin Coumans]

is there a way for me to generate this btPolyhedralConvexShape::m_polyhedron and pass it to btPolyhedralConvexShape?

There is no API for that yet, but deriving the shape would allow you to add a set/get method.

i've added a ticket to the issue tracker http://code.google.com/p/bullet/issues/detail?id=555

You are right, there is some bug in the merging of coplanar faces, it is relatively new and untested code.

Do you have a suggested patch file (using svn diff)?
Thanks a lot.
Erwin