Design patterns in Game Physics

In the frames of a number crunching compatible programming language (say.. C++), what would be an elegant solution for adding self collision, external collision and integration step (Euler, etc.) updates to an object? (say the already abused mass spring system).

Say the object class is this one:

class DeformableObject
{
public:
DeformableObject();
virtual ~DeformableObject();
protected:
vector <vec3<Real> > pos;
vec3<real> fEval(int idx); // - the internal force due to ellasticity at the idx-th node
friend class Integrator;
}


For example, in case of the integration method, I was thinking of having an abstract Integrator class and derive from it to add specific methods (Euler, Verlet, Midpoint, you name it).:

class Integrator
{
public:
Integrator();
virtual ~Integrator();
vec3<Real> Step(Real DTime, DeformableObject * dObject, int idx);
}


Now, since I'd like to switch or perhaps let different instances of the same deformable object use integration method A and the other use integration method B (for "benchmarking" purposes), is it safe to "think inside the box" and refer to either the Bridge or Strategy pattern? Which is more suitable and less ambiguous, especially performance-wise?

What about a self collision controller approach? Should I just add a self collision method to the DeformableObject class or "befriend" it with a Collider class? And what about external collisions, with different objects - how should that aspect be approached, at least at the conceptual level: considering the naive, brute pair-to-pair collision queries, if two objects collide, their points must be updated in the sense that velocities and forces are added to the points' own dynamic quantities (e.g. restitution forces, penalty forces, friction forces, reflected velocities, impulse conservation velocity changes, etc.). I know this is a broad topic, but I don't know which book does tackle these natural problems for a novice programmer. Thanks for your patience in reading this question!

• In the Update of your object, it should only change the velocity (direction * speed), not the position. In the PostUpdate, the velocity gets added to the position. In between, collisions occur, which change the velocity and the position (wiggling it) of the object. And that's how I solved it. – knight666 May 24 '12 at 13:22
• I hear that, collision handling is approached in different ways: penalty forces; velocity changes (due to the things I mentioned in the post) + restitution forces + optional friction; direct position reprojection of the penetrating points onto the external surfaces of the volumes + optional forces/ velocity changes. Different methods, different behaviour, but the implementation tips elude me a bit. I'd like to have a somewhat general schema.. – teodron May 24 '12 at 13:27

If you are looking for speed and elegance, consider a moving away from object-oriented design to a more data-oriented solution. There are several major performance problems with your design. The first Is the usage of a virtual destructor, (which is good for most object oriented design and C++ best practice, but an absolute performance killer on small objects). The second biggy is the use of an std:vector, (ie. dynamic memory allocator), in your deformable object. This kills cache coherency.

I would consider the following sources good jumping off points:

http://gamesfromwithin.com/data-oriented-design

http://solid-angle.blogspot.com.au/2010/02/musings-on-data-oriented-design.html

http://macton.smugmug.com/gallery/8936708_T6zQX#593426709_ZX4pZ (This ones a little more related to physics).

Anyway, if you come up with a nice Object-oriented design you are happy with, by all means use it. But remember that a data-oriented design will almost definetly beat it in performance.

• Thank you for the suggestion! I'll look into the paradigm right away! – teodron May 24 '12 at 14:45