_____Concave Objects with strange sheer force______

[ozmik]

Hi All,

I have some simple "U" shaped concave btGImpactMeshShape objects that are to be joined together with tight precision, like a 3D jigsaw puzzle.

The edges are all flat and at right angles to each other but when the concave surfaces come into contact with each other, a sheer force hits the moving object and it moves off along the flat surface, rather than simply stopping.

It only happens on the concave surfaces, not the outer convex surfaces.

I need the objects to rest inside tight right angles and sit still and not fly off at tangent angles.

I have played with all these settings: eg, enabling m_splitImpulse etc. ....to improve things but it doesn't go away, the weird sheer force remains.

m_tau = btScalar(0.6);
m_damping = btScalar(10.0);
m_friction = btScalar(0.3);
m_restitution = btScalar(0.0);
m_maxErrorReduction = btScalar(20.0);
m_numIterations = 10;
m_erp = btScalar(0.2);
m_erp2 = btScalar(0.1);
m_globalCfm = btScalar(0.0);
m_sor = btScalar(1.0);
m_splitImpulse = true;
m_splitImpulsePenetrationThreshold = 0.0001f;
m_linearSlop = btScalar(0.0);
m_warmstartingFactor=btScalar(0.85);
m_solverMode = SOLVER_USE_WARMSTARTING | SOLVER_SIMD;// | SOLVER_RANDMIZE_ORDER;
m_restingContactRestitutionThreshold = 2;//resting contact lifetime threshold to disable restitution
m_minimumSolverBatchSize = 128; //try to combine islands until the amount of constraints reaches this limit

Damping slows the moving object down heaps, but the sheer force seems to be throw the object off with no influence from damping.

I can't set the linear velocity to zero in the collision callback because I want the user to slide the piece along the flat concave surface as part of the process.

All the time the pieces are touching, the collision callback is firing.

I use a weak constraint to grab the piece and move it around.

The stationary pieces are "hanging" in space with their LinearFactors and AngularFactors set to zero so they do not fall with gravity.

The stationary pieces also have their massProps set to zero so that they still collide but do not fall with gravity.

I do not care about gravity at all, I want the pieces to all sit in space but join together with tight precision.

Thoughts anyone?

Cheers.

[Flix]

NOT REALLY AN ANSWER:

For such a simple concave mesh, it is far simpler and more efficient to use a btCompoundShape made of convex sub shapes (btConvexHullShapes or simply btBoxShapes).

If you want you can use libConvexDecomposition (or the new libHACD present in the latest SVN) to do the decomposition in an automatic way (this way you can avoid the problem of centering the compound shape in its geometric center too, if you center the mesh you pass to it...).

You may want to look at the appConvexDecompositionDemo for further info (although it's not too difficult to extend from the btCompoundShape class and create a concave shape from a btStridingMeshInterface, like GImpactUtils used to do with its deprecated? btGImpactConvexDecompositionShape).

[ozmik]

Thanks Flix for the info, much appreciated.

I'll check out the demo.

Pls excuse my ignorance but should a Convex Hull cover this concave bounds ok? I'm getting corruption around the concave "cutouts" on my objects.

See pics below:



The Left image is using a TriMesh bounds and the right image shows corruption for the ConvexHull. Note the Normals are not even there!!

I'm going round in circles thinking I'm coding something wrong, but maybe my Mesh is corrupt in the first place?

Just FYI....I have drawn my objects in Solidwork, exported them as STL files, Imported the STL into Blender then exported out into Xcode using the SIO2 (awesome work Rom) for final App.

If anyone has done this or similar, maybe you could "de-defuse" some light on the subject and make things a little more clear.

I'll go back to my modelling tools again if this is the problem but the TriMesh looks good for the job.

Thanks all who are viewing.

ozmik.

[Flix]

Pls excuse my ignorance but should a Convex Hull cover this concave bounds ok?

Well, I can't really know it .

Usually convex decomposition works well if the mesh if not too big/complex (and if complex collision handling, like retrieving the triangle index is not required (of course since now it is a compound shape)).

Anyway I've tried using both the "bunny mesh" and the "torus mesh" (from GImpact demo) and they worked well. Expecially libHACD seems a bit easier to tweak and a bit faster too. You may try using this wrapper class I'm making (you need to compile libHACD before using it):

btHACDCompoundShape.h

It's constructor takes a btStridingMeshInterface and some optional tuning parameters. Usage:

Code: Select all

btTriangleIndexVertexArray* triangleIndexVertexArray = [...];	//a btStridingMeshInterface* is enough...	
btHACDCompoundShape::Params params;	
params.maxHullVertices 	= 			64;			// (16) Max number of vertices in each convex hull sub shape. This is the only parameter that can be tweaked in most cases...
params.nClusters		=			2;			// (2) Min number of resulting sub shapes. Can be used to increase the number of sub shapes.
params.concavity		=			100;		// (100) Higher seems to reduce the number of sub shapes and viceversa. Can be used to increase or decrease the number of sub shapes.
params.compacityWeight	=			0.1;		// (0.1) ???
params.volumeWeight 	= 			0.0;		// (0.0) ???
params.addExtraDistPoints = 		concaveMeshHasHoles;//false;	
params.addNeighboursDistPoints = 	concaveMeshHasHoles;//false;	
params.addFacesPoints 		= 		concaveMeshHasHoles;//false;		
		
btCompoundShape* compoundShape = new btHACDCompoundShape(triangleIndexVertexArray,params);

You can increase params.maxHullVertices if you want better normals.

P.S. The class it's still a bit W.I.P. and can be extended/made better, but should work in most cases. Currently submeshes in the btStridingMeshInterface are merged together, so it's not possible to get the submesh index upon contact.

UPDATED: updated btHACDCompoundShape.h, and made a demo showing its usage, here:http://bulletphysics.org/Bullet/phpBB3/ ... =17&t=7159

[dphil]

Thanks Flix, I was going to put something together myself, but I'll try out your code. Some results I've seen using HACD do look good (though I've yet to see direct visual comparisons with Bullet's original convex decomposition). Good to hear that you've found it a bit faster too.

[dphil]

Hm...I've tried some different combinations of parameters for btHACDCompoundShape::Params, and it keeps making one child shape for every triangle in the original mesh. For example, a simple cube ends up as a compound shape with 12 children, and a large mesh of 3600 triangles ends up as a compound with 3600 children...which resulted in dreadfully slow collisions . I'm using btOgre to convert an Ogre entity mesh into a btTriangleMesh, and I pass that to btHACDCompoundShape. Will investigate further...

[khaled]

Hi guys,
Please, do not hesitate to send me any mesh (in OFF or VRML format if possible) not well handled by the HACD library. My email address (kmamou @ gmail.com)

--Khaled

[dphil]

So the reason it was making a child shape for every triangle was that my meshes were using duplicated vertices, so HACD could not "see" the connection between them for making a graph. I'll have to process my meshes appropriately. I am getting some aggregation of triangles into convex hulls now, but they seem very disorganized and do not correctly encapsulate the original mesh (sometimes sticking unexpectedly far out or missing parts of the mesh). From a little testing, I think this is on the bullet side of things (I think btHACDCompoundShape), and not HACD. Still working on it.

[dphil]

Ok, turns out that the default "true" argument for the "use4ComponentVertices" parameter of the btTriangleMesh constructor was what was messing up my code. Setting it to false works, and I'm getting some great-looking decomposition now.

[Flix]

Please, do not hesitate to send me any mesh (in OFF or VRML format if possible) not well handled by the HACD library.

Thanks (you must be the maker of HACD and of the article referenced in it: "A Simple and Efficient Approach for 3D Mesh Approximate Convex Decomposition" Game Programming Gems 8 - Chapter 2.8, p.202. A short version of the chapter was published in ICIP09 and is available at ftp://ftp.elet.polimi.it/users/Stefano. ... 003501.pdf).

Right now I've just tested 2 meshes (the bunny and the torus mesh of the GImpact demo), so no problem so far. I've just needed set the boolean parameters to "true" when decomposing the torus mesh.

BTW: you've made a great work

Hm...I've tried some different combinations of parameters for btHACDCompoundShape::Params, and it keeps making one child shape for every triangle in the original mesh.
So the reason it was making a child shape for every triangle was that my meshes were using duplicated vertices, so HACD could not "see" the connection between them for making a graph.
Ok, turns out that the default "true" argument for the "use4ComponentVertices" parameter of the btTriangleMesh constructor was what was messing up my code. Setting it to false works, and I'm getting some great-looking decomposition now.

Well, it would be interested to discover the robustness of HACD in relationship to meshes with duplicated vertices (or possible degenerate triangles): have you found something about it?


P.S. In case somebody using btHACDCompoundShape.h wants to send Khaled meshes with problems, there's a parameter for it:

Code: Select all

params.optionalVRMLSaveFilePath="";

When not empty, it should save the mesh.
[Edit:] Please don't do it: that parameter is rather useless for Bullet users, since it's supposed to save the result of the decomposition, not the original mesh...

[dphil]

Flix, can you try a simple cube and see what you get? I set some parameters assuming I would just get the same cube back from decomposition (being convex, after all), but instead I get the full cube plus another cluster consisting of *some* of the original points. Here's the setup:

Original cube has corners (-0.5,-0.5,-0.5) and (0.5,0.5,0.5). In my case it used duplicate vertices but I clean these out first (this could be an issue?). I run the cube through HACD with the following parameters:

addFacePoints = false
addExtraDistPoints = false
addNeighbourDistPoints = false
nClusters = 1 // assuming here it will just make the whole cube a cluster
concavity = 1000
compacityWeight = 0.1
volumeWeight = 0.0
nVerticesPerCH = 10000

But instead of the decomposition simply returning the original cube vertices, as I would have expected, I get 2 clusters: one with the original vertices, the other with a subset of them. I get the original cube from an Ogre mesh, but here is the decomposed output in VRML:

HACD_cube.wrl.zip

If someone else can try this, then I can see if this is something in the way I set up my cube/decomp, or if it's just how the decomposition works (in which case I wonder if it should be doing this).

[khaled]

Please, could you provide me with the input mesh?

--Khaled

[dphil]

With the updated HACD, I can now get a single convex hull for the cube with no problem. But in case you are interested, I still get the issue I mentioned above if I specify nClusters = 2. It gives 2 clusters, one with the original points, and one with a subset of them. I would have expected a division of the original vertices into two distinct, non-overlapping clusters (say, 4 vertices in one, the other 4 in the other).

Here's the original in off and wrl format:

unitcube.off.zip

unitcube.wrl.zip

I used the parameters:

addFacePoints = false
addExtraDistPoints = false
addNeighbourDistPoints = false
nClusters = 2
concavity = 100
compacityWeight = 0.1
volumeWeight = 0.0
nVerticesPerCH = 100
connectDist = 20

The output is:

unitcube_hacd.wrl.zip

[khaled]

Great.

HACD does not guaranty that the generated convex-hulls will not overlap.
--Khaled

[dphil]

Ah ok, thanks.