Effect of gravity between point A and B

I'll try not to confuse anyone with this... I have a gravity simulator built. Works pretty well, except that the math is missing one vital piece. Right now, it takes object A and computes the effect of gravity from every other object on the screen, based on mass and distance. Then it applies the total force to the current velocity and comes up with a new position for the next frame. Unfortunately, what's happening is a small object gets maybe 2 pixels from a large object, gets a LARGE boost of momentum, and the next frame it's 10 pixels away, going the other direction. This results in objects being flung around rather unrealistically. What I need to come up with is a way to calculate the total effect of gravity for every point in between points A and B, so things will balance out and behave correctly.

Does that make sense?

If so, where would be a good place to start?

Cut your time interval down.

That's not the issue, if I'm reading my own problem correctly. Besides, even cutting the time interval down, the same problem will happen. It's not factoring in gravitational attraction between points.

From my reading of it, I assumed that the problem was that your object was reaching a point where the gravitational force on it was sufficiently strong that in the next time interval, it has mysteriously moved halfway across the screen. In this case, cutting the time interval down will mean that it moves a lot less before the next calculation, allowing a more accurate trajectory to be plotted.

I don't really see what other problem there could be, assuming you have calculated the net force correctly. All you need is the sum effect of all the masses at the relevant positions to calculate the net force at a given time. The more time intervals you take, the more frequently you sample the position and hence the more regularly you update the position calc.

But you'd have to reduce it to an infinitely small time interval to get truly accurate readings. The problem is in effect what you described, but it's not as much a time interval issue as it is a computational one. At least, it wasn't until i started thinking about it...

The problem then is, how can I effectively reduce the time interval? Right now it's set on a timer... I plan to change that into a real game loop at some point.

You could run the calc more regularly than you update the graphics, i.e. calculate the new pos, rerun the calc, update the pos, rerun (etc) a few times before plotting the new position.

that would improve the accuracy for sure... I'll play around with it and see what happens. I'm just tired of watching a tight cluster of particles fling itself apart...

Gravity is an attractive force.



Are you sure you know what you're doing?




;)

What's supposed to happen when 2 particles collide, do they annihilate and disappear in a burst of energy or do you consider elastic or inelastic collisions that fling them around?

I think the best way to solve this is to change the way you move objects.

What you are doing now is calculating velocity and moving the objects X number of pixels every frame based on that velocity. This can make things jumpy and cause problems with updating position and velocity.

What you might consider doing is to instead is to move objects only one pixel at a time -- for example, base your whole simulation around 100 frames. If your formula says that an object should move 10 pixels, move it once every 10 frames, recalculating whenever you feel necessary.


Does this help?

Perhaps there's a way to improve your mathematical model to take into account infinitesimal changes in motion.

<exploring>

Take two points, P and Q, separated by a distance of R initially. What I assume you've been doing is to use F = k m_P m_Q / R² and then F = m a = m dv/dt to approximate changes in velocity for small intervals. Of course, the problem is that a = dv/dt only works as dt -> 0, giving your simulation only an approximation. Hence, Zaza suggested at the very beginning you need to decrease your dt to increase the reality of your simulation.

Is there a way to mathematically account for infinitesimal changes in objects' positions, and basically get a formula that will give you the proper location for any inputed time for any particle? Maybe. In any case it seems like it'll involve very complicated algebra, and that the simplest solution is simply to decrease dt until you're satisfied.


Simple case: using P and Q again
After an infinitesimal time dt, P and Q will move closer to each other by some very small, finite amount, changing the force of gravity exerted between them since their distance changes.

Algebraically, F_P = m_P a_P = m_P dv_P/dt = m_P Sqrt[(d²x_P/dt²)² + (d²y_P/dt²)²] = k m_P m_S / (Sqrt[(x_P - S_CMx)² + (y_P - S_CMy)²])² where S is the rest of the system minus P. In this simple case, S = Q, so m_P Sqrt[(d²x_P/dt²)² + (d²y_P/dt²)²] = k m_P m_S / ((x_P - x_Q)² + (y_P - y_Q)²)

S_CMx and S_CMy can be calculated by knowing the position of every object in S. In this case, S_CMi = Q_i.

A similar equation can be made for the position of Q:
F_Q = m_Q Sqrt[(d²x_Q/dt²)² + (d²y_Q/dt²)²] = k m_Q m_S' / (Sqrt[(x_Q - S'_CMx)² + (y_Q - S'_CMy)²])² = k m_Q m_P / ((x_Q - x_P)² + (y_Q - y_P)²) where S' is the entire system minus Q, and CM means Center of Mass, and in this simple case S' = P.


So, after all that algebra, we have a couple of (monstrous) differential equations. I wouldn't even bother attempting to solve them by hand: Mathematica has the DSolve[] function for a reason. But, can they be solved? Is there enough information given even in this simple case?

The two equations have 8 total unknowns: d²x_Q/dt², d²y_Q/dt², d²x_P/dt², d²y_P/dt², y_Q, x_Q, y_P, and x_P, meaning our system is so far horribly underdetermined. However, there's some hope: we also know that d²i_J/dt² is related to i_J for i = x, y and J = P and Q, giving 4 more equations. However, we still lack 2 equations--and I don't know how to come up with them.

Even if 2 more equations could be found, the resulting system of differential equations would be ugly in the extreme, and their solution would probably be nothing short of horrendous, most likely requiring loads of numerical approximating. And, that's only for 2 objects. To generalize this to n objects would require the use of matricies, and the automated solution of matrix differential equations.

So, after all that, it seems to me that this is wayyy to complicated to get perfectly right. It seems much better to just decrease dt. Good luck!




@Sunburnt: The sad thing is, the formula needs to change depending upon the last frame computed. I don't really think you can interpolate changes like you're suggesting here, since the changes needed change depending on what changed last change. Change. Change. CHANGE.

@timeshifter: There are 3 good things I can think of to improve the performance of your program. First, decrease dt like has been suggested (Again, and again, and again). Second, compute several time changes before drawing the change onto the screen, since much of the processing limitations you'll probably run into come from graphics draws. Third, optimize your computations.

I have a couple of ideas for this. You could use the fact that a collection of objects acts (according to Newtonian gravitation) like a single object at their center of mass with mass equal to the sum of the constituent objects' mass. So, given a group of objects A, B, and C, the gravitational force from A and B on C is the same force as a theoretical object AB on C where AB is placed directly at the center of mass of A and B, and AB has mass m_A + m_B. Each computational frame, you could compute the center of mass of the entire system and when computing the gravitational effects on a particular object L, you could move the center of mass an appropriate distance to account for subtracting out L, as well as subtracting out the mass of L from the mass of the whole system.

My second idea is simply to apply the conservation of momentum to allow you to compute the center of mass of the entire system easily. If momentum is conserved, you'll know that the center of mass of the system moves at constant (possibly 0) speed, allowing easy updates to the system's CM from one computational frame to the next.

The difficulty might be in subtracting off the object L from the whole system, but I've done enough typing on this subject for the night. If you can find an easy way to do it, you'll end up computing all gravitational effects with *much* less redundant calculation, giving your "compute gravity" routine a run time of O(n) where n is the number of gravitational objects to compute. That would rock :)

Quote:

---

Originally Posted by jemidiah

@Sunburnt: The sad thing is, the formula needs to change depending upon the last frame computed. I don't really think you can interpolate changes like you're suggesting here, since the changes needed change depending on what changed last change. Change. Change. CHANGE.

---

:lol:

Quote:

---

Originally Posted by krtxmrtz

What's supposed to happen when 2 particles collide, do they annihilate and disappear in a burst of energy or do you consider elastic or inelastic collisions that fling them around?

---

Depends what particles you're talking about and what energy they have. If you're talknig about matter and antimatter, then annihilations happen when they thermalise (i.e. kinetic energy ~kT) and their wavefunctions overlap. If they have more energy then you have to consider scattering. For example, backscattering to the surface is an important consideration when doing positron beam experiments, where you can get quite high (but tuned) positron energies. Other than particle-antiparticle interactions, you don't get annihilation... :)

Quote:

---

Originally Posted by jemidiah

...blah blah blah...

---

You can't do this calculation analytically. To predict the path of an object under the influence of multiple dynamic external forces would require a mssive amount of computation. And you can't get round it by using the centre-of-mass idea, because you are still having to do all the position calcs on all the objects, so it amounts to more-or-less the same thing. I don't think it would make a huge amount of difference.


I think that summarises what you were trying to say?

Quote:

---

Originally Posted by zaza

Depends what particles you're talking about and what energy they have. If you're talknig about matter and antimatter, then annihilations happen when they thermalise (i.e. kinetic energy ~kT) and their wavefunctions overlap. If they have more energy then you have to consider scattering. For example, backscattering to the surface is an important consideration when doing positron beam experiments, where you can get quite high (but tuned) positron energies. Other than particle-antiparticle interactions, you don't get annihilation... :)

---

No, no, I was thinking about large bodies such as asteroids or meteorites that collide with planets as in Hollywood disaster movies.

Quote:

---

Originally Posted by zaza

You can't do this calculation analytically. To predict the path of an object under the influence of multiple dynamic external forces would require a mssive amount of computation. And you can't get round it by using the centre-of-mass idea, because you are still having to do all the position calcs on all the objects, so it amounts to more-or-less the same thing. I don't think it would make a huge amount of difference.


I think that summarises what you were trying to say?

---

In a word: yes :)
In a sentance: yes, but I always have to go the long route first for some weird reason, and here I found out you have to dynamically solve a hideous system of differential equations to properly compute the positions--definately not worth it.

Ooh, at the bottom of my post were some suggestions that didn't involve an unworkable approach ;)

Quote:

---

Originally Posted by jemidiah

Ooh, at the bottom of my post were some suggestions that didn't involve an unworkable approach ;)

---

True. The first two were mine, and the third ("optimise your computations") is something that he probably shouldn't need to be told...

BTW, you can't just assume that the centre of mass moves linearly, which is a big problem with attempting to use cons. of mom. to calculate anything here. You have to calculate the net effect of all other objects on the one you're looking at, so you have to sum over n objects (n-1) times.




A better option is to try to make some judicious assumptions, if you can. For example, if you were plotting the planets in the Solar System, then you might ignore the effect of each planet on the others, because the Sun has such a dominant mass. Thus you won't be able to see orbital perturbations (which incidentally led to the discovery of Neptune) but it will make everything run a lot faster.

But if it's a generic "gravity simulator", then you have to include the lot and just take the performance hit.

Easy: Have a minimum distance or maximum force cut-off. If the limit is exceeded, ignore the force between the planets (its more accurate than having the planet shoot off).

Medium: Have a limit again, but when it is breached, reduce the time step temporarily.

Hard: Recompute the force between each planet pair at a future time based on the current force (or some other heuristic).

I would recommend the 'hard' option, because it has the added bonus of automatically giving more calculation priority to planet-moon pairs and sun-planet pairs, which gives you a performance boost.

Quote:

---

Originally Posted by zaza

BTW, you can't just assume that the centre of mass moves linearly, which is a big problem with attempting to use cons. of mom. to calculate anything here. You have to calculate the net effect of all other objects on the one you're looking at, so you have to sum over n objects (n-1) times.

---

If momentum is conserved (I know, it's a big "if" depending on the application), the center of mass should still move linearly, correct? Physics isn't my strong point, so please correct any mistakes I make. My suggestions pertained to that sub-case--I'm not even certain if they would work, but it *seems* like they should.

Also the reason I went through all the icky math was because the OP said "...except that the math is missing one vital piece." The piece he's talking about is analytically solving the problem (as we've both pointed out by now) and my post explored whether or not it could be done--for all intents and purposes, it can't. Sorry if it got too long for anyone.

And also sorry if I made it sound like those first two suggestions were my own--I meant to simply reiterate them since they were probably the OP's best bet, and add in my 2 cents on optimization in a conservation of momentum environment.

Quote:

---

Originally Posted by jemidiah

If momentum is conserved (I know, it's a big "if" depending on the application), the center of mass should still move linearly, correct? Physics isn't my strong point, so please correct any mistakes I make. My suggestions pertained to that sub-case--I'm not even certain if they would work, but it *seems* like they should.

---

Consider just the Earth-Sun system. The centre-of-mass is not exactly in the centre of the Sun, it is displaced towards Earth because the Earth's mass is finite, although small compared to that of the Sun.
As the Earth orbits, the centre-of-mass of the system must therefore move in an elliptical fashion about the Sun as well. This is not linear.



Momentum should always be conserved.


zaza

I know this has gotten a little off topic, but I think the OP's question has been answered.

In the Earth-Sun system, shouldn't the Sun move slightly as well, perhaps negating the effect of a moving Earth on the center of mass? I would think so, since all internal forces have an equal and opposite pair but--I'm just not good enough at physics to really say. I'm interested in this thought which is why I'm pursuing it. Thanks

Fair point, and after re-reading I realise that that is actually not what I meant to say. That'll teach me not to read my posts before submitting.

I shouldn't have picked a system where the objects are orbiting. Consider Earth-Mars instead. The centre-of-mass of that system is moving, because both objects are orbiting the Sun. If you include the Sun in the calculation, then you will arrive at a system where all three objects are orbiting the centre-of-mass. However, there is clearly a different gravitational force between Earth and Mars when the objects are on the same side of the Sun to when they are on opposite sides. So there has to be an effect on all the objects in the system due to this interaction. What that effect will be is going to be the hardest bit to calculate. This is what I was getting at with my comment above about perturbations in orbits, and why if you ignore them then you arrive at a lot faster way of calculating it.

I'd have to run some tests with my program to see, but if computing the center of mass of every other object is faster and as accurate as computing force from each object individually, it could speed up the program a bit... then again, running 300 objects simultaneously probably doesn't help...

It doesn't work like that, except in certain circumstances. The Moon and Earth are in a system where they are orbiting about the centre of mass of that system. The Earth is also in a system orbiting the Sun. So although the centre of mass of the whole Solar System in somewhere near the middle of the Sun, that does not mean that the net force on the Moon is also in this direction. The net force on the Moon is towards the centre of the Earth - that's what is keeping it in orbit.

The net direction of the force on you and I is in the direction of the centre of the Earth, not the centre of mass of the Solar System. So unless you are making specific assumptions, you need to work out all the forces and net them. In that way you will find out how each object behaves.

Using the centre of mass will amount to the same thing in the case of the orbits, but that is a convenient trick you can use if you know something is orbiting something else. If not, you're going to have to take the hit and do the calcs.

Makes sense now, thanks zaza.
The moon-earth force vector example made me see that you're definitely right about that "trick" not working in all cases. Thanks!

Sorry for leading you astray timeshifter.

Well, I'll admit I haven't worked on that project in a while... so no damage done :thumb: