Future of collision detect used for physics

[John McCutchan]

I have been giving the GJK vs. BVH tri-mesh collision detection in the context of physics a lot of thought lately. And I wanted to kick off a discussion about what various physics engines are using, and where the experts think things will go in the near future.

In my physics engine I have a good implementation of GJK, and I am using EPA from SOLID. Recently I added a contact manifold which is essentially the same as the one in bullet. I have not had very good results though, I get a lot of jittering/popping and the manifold rarely stabilizes. I have a suspicion that the contact manifold code is tightly tied to bullets GJK results. Also, in general I feel like the whole idea of collecting enough contact points to find a collision plane is somewhat hackish -- I can imagine scenarios where those 3-4 frames of contact point collection make a big difference in how the simulation runs. I would feel much safer if I had a good collision plane immediately.

The simplicity of GJK is very appealing, but as I have struggled with my own physics simulation (particularly in the realm of contact handling), I have started to doubt if it's the best choice for video games.

Erwin, I noticed you just made a post in another thread saying that physics engines are dropping support for complex-complex collision detection and are going down the scene-graph of convex objects approach. Do you have some insider information you could share? As a counter point, it seems ODE performs complex-complex collision detection with great results.

I would love to get a sense of where some of the proprietary physics engines are going with collision detection and contact handling.

Thanks,
John McCutchan

[Erwin Coumans]

I would love to get a sense of where some of the proprietary physics engines are going with collision detection and contact handling.

Proprietary physics engines go pretty much the same direction as Bullet Physics. Just use convex (GJK or SAT or other) instead of moving concave. Bullet will get SAT next to GJK, more as a performance comparison. Postings on the ODE forum indicate that moving trimesh doesn't work very well.

[dog]

The bullet-like approach to maintaining a contact manifold has always worked well for me.

You are probably getting popping because, in my experience, the publically available EPA implementations have certain errors with them in some situations. For instance, you should always check after expanding a 3 point simplex into a hexahedron that the hexahedron actually encompasses the origin. There were some other issues too, but it has been a while since I looked.

Of course, I may have been testing the code wrong, but if that is the case, maybe you are making the same mistakes I did.