# maxgpgpu

Member

258

207 Neutral

• Rank
Crossbones+

• Interests
Education
Production
Programming
1. ## when is "center of gravity" simplification false?

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.
2. ## when is "center of gravity" simplification false?

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!
3. ## when is "center of gravity" simplification false?

Interesting stuff. However, none of these pages answers the primary question I wanted to ask (unless I missed something).  If we ignore any twisting or stretching of objects as they pass near each other, and only pay attention to the centers of mass, in what situations do the centers-of-mass actually in reality not move in the way indicated by treating them both as point masses at their centers-of-mass?  We know for the hollow and solid sphere cases that "things change when the objects overlap", but what about other shapes like the one I mentioned, namely "two triangles" or "two round disks"? Yes, I do realize I need to decide what second, third, fourth, twenty-third order effects to ignore, but this question seems to be the first I need to resolve.  After that, I will need to decide where to draw the line and accept approximations.  One factoid that I am hoping someone can confirm is... that the centers-of-mass approximation is accurate (in terms of positions of the two centers-of-mass) at least up until the centers of mass come closer than the sum of the maximum "radius" of the two centers-of-mass (where "radius" just means the distance from either center-of-mass to the furthest point on the object).
4. ## when is "center of gravity" simplification false?

Similarly for a solid sphere, the force of gravity gradually reduces to zero as you travel through the surface and approach the center... ...but most physics engines do not simulate the force of gravity between objects because gravity is too weak to be of any effect (instead we just simulate the force of gravity from the earth) so this is irrelevant :) Are you simulating gravity between objects?   It sounds like your actual problem is do to with resolving collisions? In general, resolving object penetrations is a difficult problem, and is made easier by having thick objects that only ever penetrate a small amount. You can limit penetration by increasing the time-step, or using swept-collision detection and resolving collisions at the moment that they occur instead of after penetration has occurred.   We do swept-collision detection and we do push objects back to t=toi before we compute collision response.  So I don't think that's the problem.  All collision response seems to work fine, but when these super-thin (well, infinitely thin) objects come together, you can see that their centers seem to pull together more quickly than you'd expect (they slide face-against-face to pull the centers together, which is correct behavior if you buy into the nominal center-of-mass simplification).  And when the centers do meet, there is that crazy explosion apart that happens.  I mean, it makes sense in a way that something wacko would happen when you think about (G*m1*m2)/(d*d).  When d approaches zero, any non-zero value divided by (d*d) quickly surges towards infinity. Yes, our engine supports gravity, because our first games will take place in outer space, and we want our game/physics engine to automatically support gravity (when the game designers want and enable gravity).  Even on conventional earth-surface games, don't you need some force to push objects towards the ground (or center of earth)?
5. ## when is "center of gravity" simplification false?

In almost all 3D physics we treat 3D objects as point masses, and in most cases this is either correct or "close enough".  I know of one physical configuration this simplification is totally wrong, but wonder whether others exist (including a specific one I'll mention). The case I've known about is a hollow sphere (with one or more holes in the surface).  When any other object is outside the skin of the hollow sphere, gravity can be computed as if the object is a point mass per usual practice.  However, if another object passes through the hole in the skin, all of a sudden the gravitational attraction becomes zero... everywhere inside the hollow sphere.  A bit strange, but I can see why that's true. While testing the physics engine in my 3D game engine, I noticed what appears to be strange behavior when flat triangles come close to each other.  In my tests, the triangles have mass, as if they are very thin.  In fact they are infinitely thin, because they are simply triangles, but they behave the same when I make them very thin [3-or-more-sided] disks.  Sometimes they even explode apart (I think when the centers come close together). I realized this might be slightly similar to the hollow sphere situation in a way.  When the centers of the triangles come closer than the radius of the triangles, the point mass representation seems to have the same characteristic that makes the hollow sphere case change behavior, namely (some physical parts of each object is in opposite directions from the center of gravity (or more precisely, "some physical parts of") the other object.  It doesn't feel like exactly the same situation as the hollow sphere, but the behavior is strange and I wonder if that's because this assumption (that point masses are a valid representation) is failing big time in a similar way as the hollow sphere case. Does anyone know about this stuff and provide some comments, links, references or something? PS:  The rigid body physics and contact routines seem to work and behave properly with thick objects (where the center of masses are not super close to the external surfaces).  I don't have code to handle stacking (objects with contacts with multiple other objects), but the behavior I am seeing happens with only two objects. BTW, on a separate issue, what's the best place to read about going from "simple contacts" like I have (only 1~4 contact points on each of any two objects) to support for "arbitrary stacking"?  I'm guessing "stacking" refers to the situation where more than two objects are in contact with each other, with each contact pair having 1~4 points in contact.  I say "not more than 4 contacts" simply because my code reduces cases of more-than-4 contacts to 4 contacts to simplify processing. Thanks in advance for any tips, ideas, references.