Possible Bug in btShapeHull

Post Reply
ed_welch
Posts: 43
Joined: Wed Mar 04, 2015 6:16 pm

Possible Bug in btShapeHull

Post by ed_welch »

I just discovered something that might be a bug, but I'm not sure.
btShapeHull is a class to reduce the polygon count in btConvexHullShape (otherwise btConvexHullShape preforms very poorly)
To use it I was using the code below:

Code: Select all

    btConvexHullShape convexHullShape(
        m_pPositions->GetVertexData(), m_pPositions->GetNumVertices(), m_pPositions->GetStride()*sizeof(float));
   //create a hull approximation
	btShapeHull* hull = new btShapeHull(&convexHullShape);
	btScalar margin = convexHullShape.getMargin();
	hull->buildHull(margin);
	btConvexHullShape* pConvexHullShape = new btConvexHullShape(
		(const btScalar*)hull->getVertexPointer(), hull->numVertices(), sizeof(btVector3));	
Now, what that does is create some padding around the object, for unknown reasons and that makes them seem to float a bit above the ground when they are dropped.
Setting the margin parameter to zero won't work, because that parameter is actually ignored. You actually need to call
convexHullShape.setMargin(0);
before creating the btShapeHull.
Anyway, I post this here in case it might help some one with similiar problems.
Flix
Posts: 456
Joined: Tue Dec 25, 2007 1:06 pm

Re: Possible Bug in btShapeHull

Post by Flix »

ed_welch wrote:Setting the margin parameter to zero won't work, because that parameter is actually ignored. You actually need to call convexHullShape.setMargin(0); before creating the btShapeHull.
Good to know that this works (I assume that after the processing you can still reassign your previous collision margin).

However I remember that in one of the old set of Bullet Demos (was it the convex decomposition demo?), there was an algorithm to shrink the convex planes inward before processing (or something like that). I don't remember if that was done for converting a concave shape into convex shards or just to reduce the number of vertices of a convex shape, but your solution is much faster!

btConvexHullComputer has some arguments that can be tweaked for this purpose, but we can't choose to reduce the output number of vertices (that's why it's mainly used for processing concave shapes).

BTW: AFAIR btShapeHull creates a convex hull from vertices based on 42 (or was it 48?) directions: complex shapes all end up with 42 (or 48) vertices.
In the V-HACD library (the one that can be used for convex decomposition), there's some code that can create an optimal convex hull with a specified number of vertices: it's probably slower than btShapeHull, but less vertices means better simulation speed (but with coarser shape approximation).
ed_welch
Posts: 43
Joined: Wed Mar 04, 2015 6:16 pm

Re: Possible Bug in btShapeHull

Post by ed_welch »

Flix wrote:
ed_welch wrote:Setting the margin parameter to zero won't work, because that parameter is actually ignored. You actually need to call convexHullShape.setMargin(0); before creating the btShapeHull.
Good to know that this works (I assume that after the processing you can still reassign your previous collision margin).
No, it's using the collision margin value to create "padding" around the mesh, but then the newly created object has it's own collision margin on top of the padding.
Flix wrote: BTW: AFAIR btShapeHull creates a convex hull from vertices based on 42 (or was it 48?) directions: complex shapes all end up with 42 (or 48) vertices.
It's good to know the limitations of that class. Anyway, thanks for the info, Flix!
Post Reply