Hello,

not so much a math/physic than rather a code design oriented problem. Give a simple system for checking collisions, nothing fancy, only "does body A touch body B right now", whats a good solution for implementing a system where you can test any two shapes, without knowing what they are (so I can compare two ICollisionShape-Pointer e.g.)? Given that there is a known implementation for those two bodies, otherwise simply no collision is reported. I'm not very satisfied with my current solution, so I'm looking for ways to improve/totally new ways:

        class IVolume
        {
        public:
            
            virtual ~IVolume(void) {}

            virtual bool IsInside(const IVolume& volume) const = 0;

            virtual bool WithBox(const AABB& box) const { return false; }
            virtual bool WithOBB(const OBB& box) const { return false; }
            virtual bool WithSphere(const Sphere& sphere) const { return false; }
            virtual bool WithHeightfield(const Heightfield& field) const { return false; }
            virtual bool WithTriangle(const Triangle& triangle) const { return false; }
        };

So that is the actual interface I'm using, which has a lot of methods for certain shapes already defined. I'll show you why (let me add this is one of the points that annoy me the most):

            bool AABB::IsInside(const IVolume& volume) const
            {
                return volume.WithBox(*this);
            }        

Thats the poorly titled "IsInside" method, which checks collision between two shapes. Now thats the only way I found to being able to achieve such an each vs. any - collision: Overloading a generic method, which can be used on any shape and takes any shape, can call the correct method on the unkown shape, to pick the correct collision. Clever, huh? Well...

While this at least doesn't need RTTI, it still bums me. First of all, I have to implemented a new method in the interface for every implementation of it. Eww. Also, I potentially have to dublicate the collision implementation (AABB-OBB is different than OBB-AABB in that case, though I can get rid of that by a seperate file). So, any ideas or concrete examples how to implement this more extendable/faster (didn't I hear something about virtual being bad at this low level of "phyiscs" for caching behaviour? *ducks before getting hit for premature optimization-ism*)? Anything would be welcome!

This is one way to do it and actually has a name : Double Dispatch. Surprise, that page shows a collision sample. Yes, you need to write all the functions, but if you want to support all combinations you will do that anyway (or else throw a NotImplementedYetException or something ).

To get rid of the virtuals (if that's a problem) you could sort/filter your lists by type - or have uniform lists to begin with.

I have misgivings about the double dispatch method. I feel like it's a form of spaghetti code that forms over and over again in response to a particular type of problem so we gave it a name and sanctioned it as a design paradigm. My biggest problems with it is that it obliterates the open/closed principle and is hard to maintain. Admittedly this is an opinion many will take issue with.

Thanks all for the feedback,

as for the "advanced" techniques like GJK, axis seperation etc, while they do sound interesting, I'll skip them for now and wait until I integrate a "real" physics engine in the version 2 of my game engine. Page is bookmarked, will do a great job when I start to get serious with physics, not like my simple collision libary I have right now :)

For now, I've gone with nonoptimalrobots approach, this at least eliminates the need for changing the interface and all classes every time I add a new shape. I'll experiment with it and see if I can clean up the syntax, if so, I'll edit the code here for you to see. Thanks so far!

Note that you can also have a simple matrix of function pointers.

typedef void (*rnCollideFunc)( rnManifold&, const rnTransform&, const rnShape*, const rnTransform&, const rnShape* );
static const rnCollideFunc CollisionMatrix[ RN_SHAPE_COUNT ][ RN_SHAPE_COUNT ] =
{
	{ rnCollideSpheres, rnCollideSphereCapsule,  rnCollideSphereHull,  },
	{ NULL,             rnCollideCapsules,       rnCollideCapsuleHull, },
	{ NULL,             NULL,                    rnCollideHulls,  NULL },
	{ NULL,		    NULL,		     NULL,		   }
};

And then you simply call the function like this:

RN_ASSERT( Shape1->GetType() <= Shape2->GetType() );
rnCollideFunc Collide = CollisionMatrix[ Shape1->GetType() ][ Shape2->GetType() ];
Collide( Out, Transform1, Shape1, Transform2, Shape2, Cache );

You usually have a contact class which holds the pointers to the shapes. If you sort them on construction such that Shape1->GetType() <= Shape2->GetType() you don't need to deal with the lower collision matrix. I am using this for years and always liked its simplicity. IIRC I took this idea from the ODE.

As a side note: Someone above suggested to swap the pointers. You usually have the convention that the contact normal points from A -> B (or vice versa). So don't forget to invert the orientation of the normal as well when you flipped pointers.

Note that you can also have a simple matrix of function pointers.

Yep, that's what I do. 2D array of function pointers for intersection tests, and another for slide normal calculation. Call the intersection test with the collider's position+velocity. and If you hit something, call the normal calculation with position and velocity as separate arguments. Assuming you're not doing continuous collision detection, the normal vector is just a guess, and usually works best when the things aren't already intersecting, and some shape combos can make a more accurate (or even perfect) guess if they have the velocity too.

Shape types can either be a virtual function like nonoptimalrobot's example, or a member variable that's set when the shape is initialized. I prefer variable since the shape class doesn't usually need any other virtuals, so it saves the vtable pointer, and is a little bit faster to read a variable than call a virtual function. Plus then I don't need to make separate classes for each shape type. All shapes have a position vector and a scale vector. Spheres only actually use scale.x as the radius. Cylinders use x for radius, y for length, and don't need z. Boxes use all 3.