Hello, we have been working on a physics engine mostly based on the one from the book "Game Physics Cookbook", but we recently found a couple of issues that we'd appreciate some help with.

The most important one is: The collision detection test for OBB vs OBB results positive BUT it returns no contact points in some cases. Is this correct? or should this never happen?

The code can be downloaded here: https://github.com/gszauer/GamePhysicsCookbook, and the case is evident with this example provided on the attached file, just replace the one from the github for the attached one.

And yes, we're aware of a couple of issues mentioned on the github: https://github.com/gszauer/GamePhysicsCookbook/pulls?q=is%3Aopen+is%3Apr, but that doesn't seem to correct the problem.

Any help is greatly appreciated, thanks in advance.

CH15Demo.cpp

Or should we really change for a GJK and EPA? if so, are there any implementations not too hard to adapt to this kind of workflow?

Looking at the code you've supplied in CH15Demo.cpp it is unclear how you are achieving any output to say you are receiving collisions or otherwise, you've supplied in essence a 'main' loop which then goes off to larger branches of code such as the physicsSystem class. You should post some images to show whats happening, and your tests that show things that are unexpected compared to your expected results.

I'm not sure if you're saying your repo is "https://github.com/gszauer/GamePhysicsCookbook" or if thats the one for the official GamePhysicsCookbook source, which is actually "https://github.com/PacktPublishing/Game-Physics-Cookbook/"

If your repo is the gszauer link, you have a lot of code in the physicsSystem update loops that are intended to prevent intersection and elastically prevent overlap, which may be masking the problem.

Quote

The most important one is: The collision detection test for OBB vs OBB results positive BUT it returns no contact points in some cases. Is this correct? or should this never happen?

When the shapes are overlapping there should be a non-empty contact set. Otherwise you would have found a separating axis.

Quote

Or should we really change for a GJK and EPA? if so, are there any implementations not too hard to adapt to this kind of workflow?

Why? Is SAT the problem? it seems the SAT detects the overlap correctly. You seem to fail to create contact points in this case which has nothing to do with SAT. The SAT just gives you the axis of minimum penetration. Even with GJK and EPA you would need to find the witness features and create contact points.

I gave a bunch of presentations on this topic. Both on SAT and contact creation specifically. You can find them here. 

http://media.steampowered.com/apps/valve/2013/DGregorius_GDC2013.zip

http://media.steampowered.com/apps/valve/2015/DirkGregorius_Contacts.pdf

HTH,

-Dirk