• Create Account

# Problem getting correct orbits of planets

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

15 replies to this topic

### #1Muzzy A  Members   -  Reputation: 633

Like
1Likes
Like

Posted 18 October 2012 - 08:50 PM

Hey, I'm making a little solar system simulation for myself to have fun with.

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?

### #2Bacterius  Crossbones+   -  Reputation: 8482

Like
1Likes
Like

Posted 18 October 2012 - 10:56 PM

Did you try setting actual values for the masses, and using the universal gravitational constant? Also, you need to give each planet the correct 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).

But when I apply the force of gravity 'G = m/d^2'

This m is the sun's mass, right? Not the planet's.

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 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.

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

### #3Muzzy A  Members   -  Reputation: 633

Like
0Likes
Like

Posted 18 October 2012 - 11:34 PM

i feel like floating point inaccuracy is a part of the problem, but definately not all.

'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.

### #4Bacterius  Crossbones+   -  Reputation: 8482

Like
1Likes
Like

Posted 18 October 2012 - 11:42 PM

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

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.

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

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).

Vec3 gravityAccel = (G_Constant*objMass/distSqu) * direction ;

What is objMass?? Is it the mass of the object exerting the force, or is it the mass of the object being affected?

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

### #5Muzzy A  Members   -  Reputation: 633

Like
0Likes
Like

Posted 18 October 2012 - 11:53 PM

no no no no lol, i do this algorthm for every object there is, i don't add them all up into 1 mass ^.^ lol.

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

### #6h4tt3n  Members   -  Reputation: 1014

Like
0Likes
Like

Posted 19 October 2012 - 12:12 AM

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. Finally, ALWAYS apply opposite equal forces, otherwise your simulation will not conserve momentum. For two interacting objects a and b; when adding force f to object a, always add force -f to object b.

Cheers,
Mike

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

### #7Bacterius  Crossbones+   -  Reputation: 8482

Like
0Likes
Like

Posted 19 October 2012 - 12:16 AM

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.

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.

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

### #8Cosmic314  Members   -  Reputation: 1185

Like
0Likes
Like

Posted 19 October 2012 - 08:04 AM

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.

### #9h4tt3n  Members   -  Reputation: 1014

Like
1Likes
Like

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

### #10taby  Members   -  Reputation: 336

Like
1Likes
Like

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.

### #11Muzzy A  Members   -  Reputation: 633

Like
0Likes
Like

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.

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).

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

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

### #12taby  Members   -  Reputation: 336

Like
0Likes
Like

Posted 19 October 2012 - 05:13 PM

Post the code if you still have grief.

### #13Muzzy A  Members   -  Reputation: 633

Like
0Likes
Like

Posted 19 October 2012 - 06:38 PM

I think i'm getting it, i'll post again if i fail though

### #14h4tt3n  Members   -  Reputation: 1014

Like
0Likes
Like

Posted 20 October 2012 - 12:55 AM

Forgot to mention Muzzy, I have loads of smaller code samples with gravitational interaction. I'll post some if you'd like some working examples to look at.

Cheers,
Mike

### #15Muzzy A  Members   -  Reputation: 633

Like
0Likes
Like

Posted 20 October 2012 - 10:34 AM

Forgot to mention Muzzy, I have loads of smaller code samples with gravitational interaction. I'll post some if you'd like some working examples to look at.

Cheers,
Mike

sure, it'll be nice to have something to compare to

### #16Inferiarum  Members   -  Reputation: 731

Like
0Likes
Like

Posted 21 October 2012 - 07:14 AM

If you use the Euler method in the simulation maybe you should use something more accurate.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS