Optimisation of btBvhTriangleMeshShape collisions

elojd
Posts: 8
Joined: Sun Feb 14, 2010 8:26 pm

Optimisation of btBvhTriangleMeshShape collisions

Post by elojd »

I've got a few questions about btBvhTriangleMeshShape.

Simple and short: How do I make yellow lines shorter? :)

Image

More complex:
How do I optimize collision detection between btBvhTriangleMeshShape and other shapes?

When shape of another rigid body intersects with normals, simulation significantly slows down, even though bounding boxes of the shapes do not intersect. Also, when I drop a small object (0.1, 0.03, 0.05) on btBvhTriangleMeshShape it starts bouncing around. If it's dropped on a box, there is no problem. Is there a way to fix this? (resizing shapes is not an option, and I've tried changing simulation frequency - it doesn't help). Gravity is (0, -2, 0). Size of the drawer in the picture is (0.38, 0.22, 0.34).
User avatar
dphil
Posts: 237
Joined: Tue Jun 29, 2010 10:27 pm

Re: Optimisation of btBvhTriangleMeshShape collisions

Post by dphil »

If those yellow lines are the triangle normals, then I assume they are always going to be normalized to a length of 1. So you wouldn't/shouldn't change their length. Also, I wouldn't have thought that they should cause any sort of collision detection; they are simply a visualization of the surface orientation, that's all (again, assuming what I'm looking at here is the bullet debug drawing, and not your own lines which may mean something else). So I would hazard a guess that the slowdown you experience has nothing to do with another rigid body intersecting the normals. Rather, the bounding boxes plus their collision margins may be overlapping. I seem to recall reading somewhere that the default collision margin for a mesh is 0.04, which starts playing a relatively significant role with the small mesh sizes you are using.

Just some guesses...
elojd
Posts: 8
Joined: Sun Feb 14, 2010 8:26 pm

Re: Optimisation of btBvhTriangleMeshShape collisions

Post by elojd »

Yes, that's a bullet debug drawing. Default collision margin of btBvhTriangleMeshShape is 0, so that shouldn't cause the problem. Anyway, it seems that you're right about normals. I have a big static object with several smaller objects connected by constraints to it. It seems that when one of those objects gets activated, all of them get activated, which causes the slow down. I'm still not sure if this is the issue, because this would basically mean that activation passes through static object which shouldn't happen since it can't move, so it shouldn't be able to transfer impact to connected dynamic objects.

The second part of my question concerning small objects and btBvhTriangleMeshShape still stands.
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA

Re: Optimisation of btBvhTriangleMeshShape collisions

Post by Erwin Coumans »

We should disable the debug drawing of the normals by default, and make it a separate debug flag.

Optimizing collision detection, especially for static world triangle mesh geometry, takes time and effort.

Usually there are too many triangles in certain areas. It looks like in your case the scale is quite small, which can also cause performance issues. Typically it is best to optimize the artwork: use fewer and bigger triangles, or approximate objects with convex shapes (btConvexHullShape, btBoxShape etc).

Thanks,
Erwin
elojd
Posts: 8
Joined: Sun Feb 14, 2010 8:26 pm

Re: Optimisation of btBvhTriangleMeshShape collisions

Post by elojd »

Can you give me some guidelines for optimization of collision detection, if we assume that I'm willing to invest time and effort? Where should I look and what should I implement?

Thanks,
Milos