Gravatational pull of two objects with diffrent masses

[slicer4ever]

hello, new to these forums, and i have a question about gravitational pull of two objects
i'm trying to make a game based off of gravity's pull on objects, and have been reading through articles on gravity, i decided to go with Newton's law of universal gravatation for calculating the force being pulled on objects between other objects

anyway, I've been doing a lot of tests, and one that keeps making me think things are wrong with what I'm doing is this: http://www.swfcabin.com/open/1273370371

the left object has 10x the mass of the right object, yet they are pulled toward each other equally, which doesn't seem right, anyone care to explain why it is right, or what I'm doing wrong?

edit: sorry if this is the wrong forum, it seems the most relevant, but if it suits another part of the forum, please move it

 

[Janus]

While the force acting on each is equal, the left object has ten times the mass to be moved by that force, so it accelerates ten times slower to the right than the right object does to the left.

 

[slicer4ever]

While the force acting on each is equal, the left object has ten times the mass to be moved by that force, so it accelerates ten times slower to the right than the right object does to the left.

hmm, lol, actually i was beginning to come to the conclusion that i wasn't factoring in drag, is their a specific formula i can use to account for the drag of one object, or should i take the force calculated, and divide it by the objects mass?

edit: does this seem like an appropiate gravity response:
--random mass between 1-5, also, random missing node: http://www.swfcabin.com/open/1273377484

--each object has a mass of 1, set removed object, set size(basically, does it look like a realistic gravity response?, it kindof does to me: http://www.swfcabin.com/open/1273377894

also, any recommendations on creating a more unique response, in other words, they all clump together in 1 mass, rather than seperating into orbits around each other, or really doing anything that creates several unique masses

 

[yuiop]

hmm, lol, actually i was beginning to come to the conclusion that i wasn't factoring in drag, is their a specific formula i can use to account for the drag of one object, or should i take the force calculated, and divide it by the objects mass?

edit: does this seem like an appropiate gravity response:
--random mass between 1-5, also, random missing node: http://www.swfcabin.com/open/1273377484

--each object has a mass of 1, set removed object, set size(basically, does it look like a realistic gravity response?, it kindof does to me: http://www.swfcabin.com/open/1273377894

also, any recommendations on creating a more unique response, in other words, they all clump together in 1 mass, rather than seperating into orbits around each other, or really doing anything that creates several unique masses

In your last effort, the final clump of masses drifts up and to the right which does not seem right, because the initial momentum of the system appears to be zero. The total momentum of the system before and after the interactions should be unchanged. However, small errors in numerical simulations tend to add up and will probably always result in a small unintended error drift for any none trivial system. In Newtonian gravity simulations non trivial usually means more than two gravitational bodies and in GR simulations non trivial can mean anything more than one significant gravitational mass.

Here is a basic heuristic to work by. For a system consider each body in turn. Calculate the acceleration of the considered body by ignoring its own mass and calculating the acceleration due to each other mass in the system individually. Acceleration is a vector so you need to add all the acceleration vectors* together to get the final magnitude and direction of the acceleration of the considered body. Do this for all the other bodies in the system for each step (time increment) of the simulation. Unfortunately you can not combine the masses of the other bodies as one large effective mass and you have to consider the mass and distance of each individual body and this can take a lot of processing power. There are some shortcuts and reasonable aproximations you can make to speed up the simulation. For example a "clump" of bodies far from the considered body can be treated as a single point mass with little loss of accuracy. See http://www.amara.com/papers/nbody.html#tcu

To see a nice (fast and beautiful) gravity simulation of multiple bodies that can run on a PC see: http://gravit.slowchop.com/ It is a pure simulation rather than a game, but the source code is included and it might be helpful to you.

To make the above a bit clearer here are some simple 3 body examples (using gravitational constant G = 1).

Example 1:

Body A with mass Ma = 10 on the left at R = 0.
Body B with mass Mb = 1 at R = 10 on the right.
Body C with mass Mc = 5 at R = 10 on the right.

(1)Acceleration of A towards B and C is (Mb+Mc)/R^2.
(2)Acceleration of B towards A = -Ma/R^2.
(3)Acceleration of C towards A = -Ma/R^2.


All 3 quantities have to be calculated for each iteration of the simulation. I have treated B and C as a single body when calculating the acceleration of A, but this aproximation might be good enough for a game when r is large and B and C are close together. You will also have to calculate the mutual acceleration of B and C towards each other and do the vector additions.

Example 2:

Body A with mass Ma = 10 on the left at Ra = 0.
Body B with mass Mb = 1 at Rb = -5 on the left.
Body C with mass Mc = 5 at Rc = 10 on the right.

(1)Acceleration of A = -Mb/Rb^2 + Mc/Rc^2.
(2)Acceleration of B = Ma/Rb^2 + Mc/(Rc-Rb)^2.
(3)Acceleration of C = -Ma/Rc^2 - Mb/(Rc-Rb)^2.

The above calculations are rough and ready, but it might give you sufficient idea of the principles involved to create a simulation that is realistic enough for a game. Note that I am dealing with accelerations rather than forces, because all you need to know is how things move over time. Hope that helps.

*See http://academicearth.org/lectures/vectors-dot-products-cross-products-3d-kinematics for how to "add vectors".

 

[LukeD]

Oh no! Your system oscillates around the center at the end in this one: http://www.swfcabin.com/open/1273377894
That's definitely not right. If your system starts off at rest, then it should clump together and then be stationary. It's ok if the individual particles are moving a bit, but since the whole collection of masses started off at rest, it should remain at rest.

You asked if you should "divide by mass to get drag". That doesn't really make much sense. But you do "divide by mass to get inertia"
Don't forget Newton's force law "F=ma". The acceleration of a particle with mass m is "a=F/m"

 

[starthaus]

Example 2:

Body A with mass Ma = 10 on the left at Ra = 0.
Body B with mass Mb = 1 at Rb = -5 on the left.
Body C with mass Mc = 5 at Rc = 10 on the right.

(1)Acceleration of A = -Mb/Rb^2 + Mc/Rc^2.
(2)Acceleration of B = Ma/Rb^2 + Mc/(Rc-Rb)^2.
(3)Acceleration of C = -Ma/Rc^2 + Mb/(Rc-Rb)^2.

Actually, eq (3) is incorrect. It is easy to see that A and B accelerate C in the same direction (the -x direction). You can find the correct general equation of motion here

For two bodies, the problem reduces to solving a system of two second order differential equations. The solution is not trivial. You would need to solve:

\frac{d^2\vec{r_A}}{dt^2}=GM_B\frac{\vec{r_A}-\vec{r_B}}{(r_A-r_B)^3}\frac{d^2\vec{r_B}}{dt^2}=GM_A\frac{\vec{r_B}-\vec{r_A}}{(r_A-r_B)^3}

]

 

[yuiop]

Actually, the above is incorrect. The correct formalism is more complicated. You can find the correct equation of motion here

Yes, it gets much more complicated when you take linear and angular momentum etc into account. It depends how realistic you want the game to be and how much computational power you have available.

 

[starthaus]

Yes, it gets much more complicated when you take linear and angular momentum etc into account. It depends how realistic you want the game to be and how much computational power you have available.

I was talking about something a lot more basic:


(3)Acceleration of C = -Ma/Rc^2 - Mb/(Rc-Rb)^2

 

[yuiop]

I was talking about something a lot more basic:


(3)Acceleration of C = -Ma/Rc^2 - Mb/(Rc-Rb)^2

AH I see.. I made a typo with the sign of the second term, which I have now corrected in the original (#4).

Thanks for the proof read ;)

 

[starthaus]

hmmm... what do you suggest the answer is to a first aproximation?

You got the sign of the second term wrong.

 

[yuiop]

Yes, it gets much more complicated when you take linear and angular momentum etc into account. It depends how realistic you want the game to be and how much computational power you have available.

Perhaps I should of mentioned in #5 that you need to keep track of the instantaneous velocities of all the bodies and apply the calculated acceleration to each body's instantaneous velocity at each iteration. For a small body in circular orbit around a very large body, the acceleration of the orbiting body is at right angles to its instantaneous velocity. Good point Starthaus.

 

[slicer4ever]

wow, i come back, and their are plenty of posts, first thank you to everyone whom has responded

up until today, this is what I've created: http://www.swfcabin.com/open/1273481279

from research and collation with some friends, that is what I've come up with, after reading through your posts i should be able to modify it to be a bit more realistic, also you'll notice collision's don't occur, i took them out actually, i felt it gave a nicer creation of unique rotations, also, i limit the speed of any object, just enough to break away from other objects, and not soo fast it's just a blur

time for my nice long reply to everyone

In your last effort, the final clump of masses drifts up and to the right which does not seem right, because the initial momentum of the system appears to be zero. The total momentum of the system before and after the interactions should be unchanged.

this is a hard concept for me to understand, while they start at rest, the attraction to each other mass's increments an increase in momentum, unless your referring to the after, being when they have collided with each other, in which case, i can understand that they should be at rest, however if u noticed, my collision code isn't perfect, and the efficiency of each impact is not perfect as well, so i suspect that the reason for the clumping, and maintaining of momentum is somewhere in the way i handle collisions

Here is a basic heuristic to work by. For a system consider each body in turn. Calculate the acceleration of the considered body by ignoring its own mass and calculating the acceleration due to each other mass in the system individually. Acceleration is a vector so you need to add all the acceleration vectors* together to get the final magnitude and direction of the acceleration of the considered body. Do this for all the other bodies in the system for each step (time increment) of the simulation.

this is exactly what i came up, each object's calculates a vector to each other object, which are all combined to the object's current vector

Unfortunately you can not combine the masses of the other bodies as one large effective mass and you have to consider the mass and distance of each individual body and this can take a lot of processing power.

yes, the processing power is something I'm running into for large scale number of objects, I've seen flash support 4000 objects in real time, so I'm not certain what I'm doing wrong in particle managment to increase efficiency(perhaps it's as simple as I'm using as 2.0, and not 3.0)

There are some shortcuts and reasonable aproximations you can make to speed up the simulation. For example a "clump" of bodies far from the considered body can be treated as a single point mass with little loss of accuracy. See http://www.amara.com/papers/nbody.html#tcu

i had considered creating a system which combined clumps of objects into sectors with a mass = to the mass of all the objects, it's just something i haven't implemented yet

To see a nice (fast and beautiful) gravity simulation of multiple bodies that can run on a PC see: http://gravit.slowchop.com/ It is a pure simulation rather than a game, but the source code is included and it might be helpful to you.

i'll take a look at this right away, thanks for linking me to this

Oh no! Your system oscillates around the center at the end in this one: http://www.swfcabin.com/open/1273377894
That's definitely not right. If your system starts off at rest, then it should clump together and then be stationary. It's ok if the individual particles are moving a bit, but since the whole collection of masses started off at rest, it should remain at rest.

ah, more re-assurance as to the before/after rest issue i have, i believe it has to do mostly with my collision implementation that creates the drag(if u'd notice, the objects well begin to move over each other, this is a by-product of trying to ensure that i didn't loop forever, re-calculating new collisions, and is most likly the cause for the non-rest issue)

You asked if you should "divide by mass to get drag". That doesn't really make much sense. But you do "divide by mass to get inertia"
Don't forget Newton's force law "F=ma". The acceleration of a particle with mass m is "a=F/m"

ah, yes, that's exactly what i meant, I'm sorry for the wording, I'm not the best at knowing all the words in physics, thanks for picking up on what i meant=-)(thankfully the concept is equal to how i implemented it, so that's a plus)

Actually, eq (3) is incorrect. It is easy to see that A and B accelerate C in the same direction (the -x direction). You can find the correct general equation of motion here

For two bodies, the problem reduces to solving a system of two second order differential equations. The solution is not trivial. You would need to solve:

\frac{d^2\vec{r_A}}{dt^2}=GM_B\frac{\vec{r_A}-\vec{r_B}}{(r_A-r_B)^3}\frac{d^2\vec{r_B}}{dt^2}=GM_A\frac{\vec{r_B}-\vec{r_A}}{(r_A-r_B)^3}

]

unfortunately this is the problem with trying to read through wikipedia's math, their are a lot of symbols their that i simply don't understand(actually since I'm quoting you, i can see all the symbols written around their meanings, which helps me understand it much more)

Yes, it gets much more complicated when you take linear and angular momentum etc into account. It depends how realistic you want the game to be and how much computational power you have available.

could you elaborate upon linear and angular momentum, at least in a context of how they relate to gravitational pull(i'm assuming quite a bit, but isn't momentum inherently linear along w/e line it's moving?)

I was talking about something a lot more basic:(3)Acceleration of C = -Ma/Rc^2 - Mb/(Rc-Rb)^2

Perhaps I should of mentioned in #5 that you need to keep track of the instantaneous velocities of all the bodies and apply the calculated acceleration to each body's instantaneous velocity at each iteration. For a small body in circular orbit around a very large body, the acceleration of the orbiting body is at right angles to its instantaneous velocity. Good point Starthaus.

hmm, I'm not really certain i understand what you mean by instantaneousthanks again everyone for your help thus far=-), I'm very grateful

also thanks for moving it to the appropriate section