but I want to use a dynamic concave trimesh.

[shotgunnutter]

Hi,

I am fully aware that these objects are not as efficient and can cause issues. However, I want to use a concave mesh for the approximation of the body of vehicles, as well as certain objects where the accuracy would suffer badly from using a convex hull. I commented out the "assert 0" in btTriangleMeshShape::calculateLocalInertia. and my trimeshes now move.

<btw> I was mildly annoyed at getting "assert 0" rather than something more descriptive such as :
"assert( !"erm, you dont want to do this, mate") </btw>

Only the occasional physics object will be done via a concave mesh. I understand that bullet uses GIMPACT to resolve concave vs concave trimesh collisions. The alternative is to break objects into a collection of convex blobs, but if I can get away with concave trimeshes, I will take my chances.

[AlexSilverman]

I was messing around a while back and made the same change you did to "enable" moving triangle mesh support in Bullet, and I noticed that while it worked, the collision detection was not accurate anymore. I saw that the collisions were generally in the same area as I would expect, but the behavior was non-uniformly wrong. I didn't pay it any mind, as I was using Bullet in a non-intended way, so I undid the change and carried on my way.

Bullet proper (that is, the Bullet library with none of the Extras compiled in) does support concave triangle meshes, but does not support moving triangle meshes (concave or convex). Bullet uses the GImpact library for moving triangle mesh support, not just for concave-concave response. If you desire moving triangle mesh support, then using GImpact is probably the better option.

- Alex

[shotgunnutter]

Hmm, I'm having a problem; trimesh vs trimesh collisions are not being detected. I've created my world, and am adding a series of dynamic objects using the factory pattern. My prototypes store the btCollisionShape of each dynamic object. When I spawn them, I add a new btRigidBody and attach that collisionshape to it.


What I'm seeing is that the dynamic trimeshes, when hitting a cube that I placed for testing purposes, are hitting it and stopping. However, when they hit the trimesh, they do nothing and fall right through it. As mentioned above I have activated the dynamic trimesh code by removing the assert(0), but I think there may be other steps I need to take to enable static trimeshes. Is this the case?

Also, when I use a sphere for the collisionShape of each physics object, they hit an invisible flat surface and slide to the -x direction. What is going on with that? I've run out of things to test.
I know some people will suggest that I don't use trimeshes, but instead use convex objects; but this would not provide an acceptable level of accuracy. Consider a slight crater in the road; this would be ignored by a convex hull.

[AlexSilverman]

shotgunnutter,

Since Bullet does not support moving triangle meshes, it can safely assume that any triangle mesh shapes (btBvhTringleMeshShape) are static, and thus it ignores any collisions between them, since it doesn't matter if static world geometry is colliding or not. GImpact is not subject to this assumption, as it uses a different shape type, so it will accurately collide with any other shape you have loaded (provided the appropriate collision algorithm has been loaded as well).

You should really use GImpact if you want moving trimesh support. It's not a question of convex versus concave. It's a question of dynamic versus static. Bullet supports convex and concave meshes, but they must be static. GImpact should be used if you want accurate simulations with dynamic triangle meshes.

As for the sphere situation, if you can reproduce this behavior in a Bullet demo people can lend a hand much more easily.

Hope this helps.

- Alex

[shotgunnutter]

Supposing I have my dynamic objects represented by convex hulls, and convex triangle meshes for the scenery, what are my options? There is an obvious accuracy issue with using convex hulls to test physical interaction with what will be drawn on the screen as arbitrary triangles. I will be able to settle for convex hulls for dynamic objects, but the scenery *must* be trimeshes or else there will be some laughable results, such as objects coming to rest in mid air, and bouncing off of invisible surfaces. Using cubes and spheres to represent dynamic objects is out of the question.

How can I enable GIMPACT? I have the standard build, I downloaded the 2.68 release.

[Erwin Coumans]

Supposing I have my dynamic objects represented by convex hulls, and convex triangle meshes for the scenery, what are my options? There is an obvious accuracy issue with using convex hulls to test physical interaction with what will be drawn on the screen as arbitrary triangles. I will be able to settle for convex hulls for dynamic objects, but the scenery *must* be trimeshes or else there will be some laughable results

AlexSilverman is right.

• For static scenery, with mass zero, simply use btBvhTriangleMeshShape.
• For moving, dynamic objects, with positive mass, use either convex objects (sphere, box, cylinder, cone, convex trimesh), a concave combination of convex shapes using btCompoundShape, or GIMPACT for moving concave triangle meshes.

How can I enable GIMPACT? I have the standard build, I downloaded the 2.68 release.

Please check out Bullet/Demos/MovingConcaveDemo on how to use GIMPACT.

In a nutshell, use btGImpactMeshShape instead of btBvhTriangleMeshShape, and register the collision interactions with GIMPACT using:

Code: Select all

///add those includs
#include "GIMPACT/Bullet/btGImpactShape.h"
#include "GIMPACT/Bullet/btGImpactCollisionAlgorithm.h"
///and after initialization of the dynamics world
 btCollisionDispatcher* dispatcher = new btCollisionDispatcher(collisionConfiguration);
///initialize the dynamics world and then
 //register the GIMPACT collision algorithm
        btGImpactCollisionAlgorithm::registerAlgorithm(dispatcher);

And link against the GIMPACT libraries (libGIMPACT and libGIMPACTUtils).
Hope this helps,
Erwin

[shotgunnutter]

Thanks, I'll take GIMPACT for a spin tomorrow, and report taste.