**1**

###
#1
Members - Reputation: **732**

Posted 18 October 2012 - 08:50 PM

Problem is, I have all the planets at the correct distance that they should be away from each other, and each given the correct average velocity

But when I apply the force of gravity 'G = m/d^2', they don't orbit correctly. All of the outside planets make their way in towards the sun and eventually get launched out of orbit forever. I've been plugging in random values into their 'mass' and trying to fake my way through it, but it's not working.

If everything is set the way it's supposed to be, mercury gets it's correct orbit, venus is a little off, earth is a little more off and etc.

What could I do to make this work the way it's supposed to? I have a book on Orbital Elements, but I'm trying not to use orbital elements, because I want it to be more dynamic, so I can add random objects that would affect everything like real life.

So what more could i do with 'G = m/d^2' to get a correct orbit for each planet?

###
#2
Crossbones+ - Reputation: **9977**

Posted 18 October 2012 - 10:56 PM

*tangential*velocity depending on where it's located at the orbit (because orbits are not perfectly circular, so the velocity of the planet is not constant).

This m is the sun's mass, right? Not the planet's.But when I apply the force of gravity 'G = m/d^2'

What is your timestep? If it's too big errors will quickly creep in the simulation and ruin it. This could also be due to floating-point inaccuracy, losing a bit of precision every tick.If everything is set the way it's supposed to be, mercury gets it's correct orbit, venus is a little off, earth is a little more off and etc.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

- *Pessimal Algorithms and Simplexity Analysis*

###
#3
Members - Reputation: **732**

Posted 18 October 2012 - 11:34 PM

'm' is the mass of everything, including the sun. Gravity from all objects affect all objects.

I have no tangential velocity, i just have normal velocity being affected by gravity.

I'm using the Universal Gravitational Constant.

i scaled all the masses and the Gravitational constant just a bit to try to avoid floating point error.

I imagine that could be a problem as well?

// time step is based off the time between frames float dt; const double G_Constant; Vec3 gravityAccel = (G_Constant*objMass/distSqu) * direction ; velocity -= gravityAccel * dt;

**Edited by Muzzy A, 18 October 2012 - 11:39 PM.**

###
#4
Crossbones+ - Reputation: **9977**

Posted 18 October 2012 - 11:42 PM

Woh woh woh, what? Do you mean you sum up the gravitational accelerations from each object, right? You can't just take the sum of the mass of everything like that.'m' is the mass of everything, including the sun. Gravity from all objects affect all objects.

For objects in orbit, you can define a new coordinate system based on the tangent of the object with respect to the orbit. By definition, objects in orbit have velocity only in the tangential direction. Direction matters. If you don't set the velocity in the right direction the orbit will obviously be different (although in any case it will still form an orbit if the velocity is less than escape velocity).I have no tangential velocity, i just have normal velocity being affected by gravity.

What is objMass?? Is it the mass of the object exerting the force, or is it the mass of the object being affected?Vec3 gravityAccel = (G_Constant*objMass/distSqu) * direction ;

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

- *Pessimal Algorithms and Simplexity Analysis*

###
#5
Members - Reputation: **732**

Posted 18 October 2012 - 11:53 PM

and objMass is the mass of another object, not itself, sorry for making it a little cryptic lol.

distSqu is the distance between the 2 objects squared.

I may have to look up tangential velocity then

###
#6
Members - Reputation: **1413**

Posted 19 October 2012 - 12:12 AM

Cheers,

Mike

**Edited by h4tt3n, 19 October 2012 - 12:12 AM.**

###
#7
Crossbones+ - Reputation: **9977**

Posted 19 October 2012 - 12:16 AM

No. F = ma. a = F/m, and the force is defined as F = G m1m2/r^2, so a = F/m = G m/r^2. This is correct. Gravitational acceleration is independent of the "receiving" object's mass.The value of gravityAccel is actually a force, not acceleration. You need to multiply it with mass to get the proper acceleration. Also, you need to include the masses of both objects in your gravity equation.

**Edited by Bacterius, 19 October 2012 - 12:17 AM.**

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

- *Pessimal Algorithms and Simplexity Analysis*

###
#8
Members - Reputation: **1374**

Posted 19 October 2012 - 08:04 AM

Bacterius is correct. You have to supply the correct tangential velocity.

###
#9
Members - Reputation: **1413**

Posted 19 October 2012 - 08:28 AM

No. F = ma. a = F/m, and the force is defined as F = G m1m2/r^2, so a = F/m = G m/r^2. This is correct. Gravitational acceleration is independent of the "receiving" object's mass.

Yes, you are completely right - But only if you pick the right mass, and I suspect this is where the error lies. Bugs are often harder to find in optimized, compacted code, and that's why I recommend using the original Newtonian force based equation. Also, for the acceleration based calculation to work you need two equations, one for each body. A1 = G m2/r^2 and A2 = G m1/r^2. Otherwise your simulation will not conserve momentum. Sorry if my first post was a bit unclear, I was in a bit of a hurry when writing it.

Cheers,

Mike

###
#10
Members - Reputation: **336**

Posted 19 October 2012 - 11:06 AM

I may have to look up tangential velocity then

Calculating the tangential velocity based on orbit parameters like distance/eccentricity:

http://www.gamedev.n...58#entry3961958

Periapsis velocity:

v = sqrt((G*M/a)*(1 + e)/(1 - e)).

The planet Mercury's semi-major axis a = 57909176e3 metres, and has an orbit eccentricity e = 0.20563069:

v = sqrt((6.6742e-11 * 1.988435e30 / 57909176e3) * (1 + 0.20563069) / (1 - 0.20563069)),

v = 58976.3015.

That's very close to the maximum orbit speed of Mercury, as 58980 m/s on wikipedia.org.

(Note, 1.988435e30 == Sun's mass)

Oppositely, for the apoapsis velocity:

v = sqrt((G*M/a)*(1 - e)/(1 + e)),

v = 38858.47.

For a circular orbit, the eccentricity is 0.

These calculations help you find the length of the tangential velocity vector. As for finding the direction of the tangential velocity vector, the cross product operation will help you (if your orbit plane is nice and aligned with the coordinate system, it's very straightforward).

**Edited by taby, 19 October 2012 - 11:15 AM.**

###
#11
Members - Reputation: **732**

Posted 19 October 2012 - 03:23 PM

You could experiment a little. Take two masses and draw them traveling at some random velocity (this implies direction too). Have a toggle button that either skips the gravitational force calculations or turns it on. When the button is toggled off all objects should continue in a straight line from their last computed velocity. This is an example of one of Newton's laws, an object at rest tends to stay at rest, an object in motion tends to stay in motion unless they are acted upon by an outside force. In particular this motion is linear. Then, click the toggle button to start computing gravitational force on each of the objects and soon they should be moving on a curved trajectory, assuming their velocity has some tangential component relative to the other.

Bacterius is correct. You have to supply the correct tangential velocity.

Already did something similar to that a while back lol.

you're going into orbital elements, which was what i was trying to avoid lol. But i see your logic.

I may have to look up tangential velocity then

Calculating the tangential velocity based on orbit parameters like distance/eccentricity:

http://www.gamedev.n...58#entry3961958

Periapsis velocity:

v = sqrt((G*M/a)*(1 + e)/(1 - e)).

The planet Mercury's semi-major axis a = 57909176e3 metres, and has an orbit eccentricity e = 0.20563069:

v = sqrt((6.6742e-11 * 1.988435e30 / 57909176e3) * (1 + 0.20563069) / (1 - 0.20563069)),

v = 58976.3015.

That's very close to the maximum orbit speed of Mercury, as 58980 m/s on wikipedia.org.

(Note, 1.988435e30 == Sun's mass)

Oppositely, for the apoapsis velocity:

v = sqrt((G*M/a)*(1 - e)/(1 + e)),

v = 38858.47.

For a circular orbit, the eccentricity is 0.

These calculations help you find the length of the tangential velocity vector. As for finding the direction of the tangential velocity vector, the cross product operation will help you (if your orbit plane is nice and aligned with the coordinate system, it's very straightforward).

**Edited by Muzzy A, 19 October 2012 - 03:24 PM.**