# Spherical / Relative Gravity

I'm working on an Ogre3D + Bullet project that involves planets in a solar system. For all intents and purposes, I'm looking to give each planet it's own gravity sphere.

So far, all I've found are ways to change the "general" gravity Vector3 for the entire scene, but that's it.

While I'd hope to add air friction and other physics later on, for now I just want "prioritized" gravity, like in this video.

You'll note that the floor in the video has gravity, but when he jumps near the sphere, he is attracted to it sphere instead. That's exactly what I'm going for.

The video is very low quality and doesn't explain how any of it is working, besides the fact that it uses Ogre3D and Bullet.

The planets themselves are on pre-generated paths around the Sun - I'm not looking to apply "real" physics to the solar system itself; just for the planets themselves and eventually "generated gravity" for ships in space.

Well I don't think that Bullet physics support multiple attractors out of the box, even though in bullet you can set the gravity per object, Bullet still assumes the objects are being simulated under a global gravity value set for the entire scene, in other words it assumes that the objects gravitational force is neglected in comparison to the planet/surface they dwell on, which is clearly not the case of real planets.

### The Solution

Never the less, I can recommend you set the global gravity to 0.0 and simulate planets' gravity using Newton's law of universal gravitation based on each planet's mass, now when any planet is within the other planets gravitational distance you can calculate the force, which can be done using a btSphereShape collider.

After you calculate the gravitational force for each planet you can apply it's gravity on other planets using btRigidBody::applyForce.

### The problem though...

Well if you ever heard of the three-body problem you will know that calculating gravitational force between three planets is particularly unsolvable (or hard to solve?) , quoting from Wikipedia:

In its traditional sense, the three-body problem is the problem of taking an initial set of data that specifies the positions, masses and velocities of three bodies for some particular point in time and then determining the motions of the three bodies, in accordance with the laws of classical mechanics (Newton's laws of motion and of universal gravitation).

This will make you approximate the actual motion of the planets rather than calculate the exact one. By reducing the problem to one static body, and calculating the motion of the other body. Then you will find that the motion of a body under gravity is an ellipse.

But that's not a huge problem, since you will get a fine approximation, quoting from this article

But even with just mechanical pencil and paper there are cheats. For example, although there are more than three bodies in the solar system (the Sun, eight planets, dozens of moons, and millions of asteroids and comets), almost everything behaves, roughly, as though it were in a two body system. Basically, this is due to the pronounced size differences between things. As far as each planet is concerned, the only important body in the rest of the universe is the Sun. To get some idea of why; the Sun pulls on the Earth about 200 times harder than the Moon, and about 20,000 times harder than Jupiter. Nothing else even deserves a mention. So, if you want to calculate the orbits of all the planets, a “2-body approximation” will get you more than 99% of the way to the right answer.

• Excellent answer. You've set me on the right path. Thanks very much! – Phillip Elm Dec 21 '13 at 20:35

One way you can do this is to setup a sphere ghost collider and detect when something collides with it. Then you can change the gravity vector to point towards the centroid of your planet for anything that collides with it that you want gravity to affect.

A much harder way to do this would be to concoct your own constraint. The constraint would be very similar to a soft distance constraint so the jacobian and implementation would be very similar to a standard distance constraint. However, the error correction would have to be calculated differently.

A standard distance constraint uses the distance from center as an error, instead you would want a distance from the affect horizon (the spherical boundary of where gravity stops affecting things). You would probably also have to increase the frequency of the oscillator as the error grows larger to mimic actual gravitation equations.

The benefit of the "harder" way would be you can probably get rid of the need to do a lot of collision detection, which is awesome. The easier way (ghost collider) will have the issue of tons of things being attracted to a large planet. This is a nightmare for the dynamic AABB broadphase, as the objects all piling towards the target centroid will create a closer and closer to N^2 broadphase lookup the closer they get to each other.