I have created following class
[java]
package com.jme3.bullet.collision.shapes;
import java.nio.FloatBuffer;
import javax.vecmath.Vector3f;
import com.bulletphysics.collision.shapes.ConvexHullShape;
import com.bulletphysics.util.ObjectArrayList;
import com.jme3.bullet.util.Converter;
import com.jme3.scene.Mesh;
import com.jme3.scene.VertexBuffer.Type;
public class ConvexHullCollisionShape extends CollisionShape {
private Mesh mesh;
public ConvexHullCollisionShape(Mesh mesh) {
this.mesh = mesh;
createShape();
}
protected void createShape() {
FloatBuffer vertices = mesh.getFloatBuffer(Type.Position);
vertices.rewind();
ObjectArrayList<Vector3f> points = new ObjectArrayList<Vector3f>();
int size = mesh.getVertexCount();
for ( int i =0; i < size; i++ ) {
points.add(new Vector3f(vertices.get(),vertices.get(),vertices.get()));
}
cShape = new ConvexHullShape(points);
cShape.setLocalScaling(Converter.convert(getScale()));
cShape.setMargin(margin);
}
}
[/java]
Is it really everything which is needed to get it working? So far, works a charm (a lot better than GImpactCollisionShape and MeshCollisionShape - I have regular, convex solids).
The read and write methods are missing, so one cannot save this collisionshape. The dangerous thing about this is the fact that the shape has to be convex but you could supply anything via the constructor really. So some kind of check would be nice.
Read-write method I agree, should be added.
As for the convexity of the shape, I don’t think it is needed - as far as I understand, idea of the this collision shape is to simulate a convex hull on top of possibly non-convex geometry (so if you want to have a torus rolling around, but don’t want to bother CPU with possibility of something falling through the middle, you use this one).
Oh, ok, cool. Didnt know that, I thought the shape had to be convex. So you say it makes it convex? Is that reflected in the collision shape too? (reminds me, the debug shape also has to be put in for this)
I was kind of hoping for somebody to confirm it, rather than ask me - I’m just coding blindly here. I must say that jbullet/bullet documentation is bit lacking. From bullet API
The btConvexHullShape implements an implicit convex hull of an array of vertices.
as opposed to for example
The btConvexPointCloudShape implements an implicit convex hull of an array of vertices.
and from pdf user manual
Convex Hull Shapes
Bullet supports several ways to represent a convex triangle meshes. The easiest way is to create a btConvexHullShape and pass in an array of vertices. In some cases the graphics mesh contains too many vertices to be used directly as btConvexHullShape. In that case, try to reduce the number of vertices.
And that’s it - I have not found anything more about the subject.
My understand is that it is working on collection of points and is simulating rigid solid filling out the space between all given points. It is probably a lot more efficient than anything based on triangles - at my program behaves a lot faster for complicated models using this point-based approach rather than triangle one (but I anyway implemented simplified colission mesh).
Debug shape would have to be probably implemented as point mesh.
Right, bullet api is not very well documented, I know that problem too I will have to check the code, but if thats really the case its great news, I will add it to the jmp wrappers any way
Hey, I just added a HullCollisionShape class based on your code and findings to svn, thanks very much for this input, I would have thought forever that I’d have to “convexize” the mesh before by hand It works like a charm, its used in TestFancyCar now. I also updated the debug shape generation so one can see the results properly.
Now the fancy car is no longer a box collider, but a fancy car collider!