One obvious problem is that the center of masses might come in contact with each other. If an object collides with Earth, it is separated by the Earth's radius before it hits the center of mass. The prevents the "infinite acceleration" artifacts you might be seeing.
You might consider modeling a distance around the body for which the object is considered collided with it to eliminate the effect.
when is "center of gravity" simplification false?
I don't understand what part of the question remains unanswered. Other than in the case of rotationally-symmetric objects (i.e., spheres whose density can depend on distance to the center only), the field will not be equivalent to that generated by a single particle. Of course you can still use the substitution as an approximation, but whether the approximation is good enough or not depends on your needs.
Now, this is a game development forum. Do you have a game in mind where these kinds of mechanics would be relevant? If you don't, that's OK with me; I am just curious.
Okay, seems like you're saying the "center of mass" approximation isn't valid even when objects are far apart (further apart than the sum of their maximum radii). Hmmmm.
Two answers to your other question. I consider the engine to be a 3D simulation/physics/game engine. OTOH, I do admit that the focus is still real-time performance, so we do not anticipate pushing for exact formula in every situation, especially if it kills performance too much (below 30FPS minimum on highish-end CPUs/GPUs, probably).
Also, our first couple planned games take place in space (zero gravity, except for local objects). Well, sometimes. It will also have to support being in the vicinity of one or a few large objects (planets and their moons) in addition to nearby small objects (asteroids, space-habitats, spacecraft). Though gravity doesn't make floating objects move towards each other very fast, it is relevant over minutes, much less hours. And because (in some situations) activity happens very slowly in space, the games will probably have a way to specify a sort of "fast forward" that increases the physics interval but keeps the frame interval. In that situation, gravity in most space environments we envision will be quite relevant!
One obvious problem is that the center of masses might come in contact with each other. If an object collides with Earth, it is separated by the Earth's radius before it hits the center of mass. The prevents the "infinite acceleration" artifacts you might be seeing.
You might consider modeling a distance around the body for which the object is considered collided with it to eliminate the effect.
My temporary short-term hack (which might be okay long-term too, since in actual practice we shouldn't have very many infinitely thin objects) is to make the gravity computation set a minimum on center-of-mass distance before it performs the computation. I think my temporary choice was somewhere between 0.000001 and 0.001 meter. What is especially convenient and efficient to model as infinitely thin surfaces is pieces of exploded objects. To give an actual thickness not only requires twice as many triangles (to create both sides of the thin piece), but also more vertices to seal up the edge thickness.
struct ObjectForGravityPurposes {
Point center_of_mass;
float mass;
float radius;
};
Now, when computing the acceleration induced by this object on points in space (where other objects' centers of mass are), use the usual formula with 1/d^2 for points outside of the sphere, and replace 1/d^2 by d/radius^3 for points inside the sphere.
This is motivated by thinking of your objects (for gravity purposes) as being uniform-density spheres. These are ghostly spheres that can pass through each other, since you won't use this model for collision purposes.