That was me trying to have a small particle making an 8-shaped path around two bigger ones that would be sufficiently far apart to not interact too strongly with each other. Of course, when the small particle went between the two bigger ones, it shifted their position a tiny bit, but sufficiently for those two to start very slowly moving towards each other, while the small particle was headed straight to the up-right direction. But when the two bigger particles became close enough to finally meet and become one single huge particle, it attracted back the small one, which since then goes back slowly to the huge particle only to shift it a bit and be "relaunched" by it for a new lap. The system seems to be totally stable that way.
> That was me trying to have a small particle making an 8-shaped path around two bigger ones that would be sufficiently far apart to not interact too strongly with each other.
This kind of path is called a free return trajectory and was used in the Apollo program lunar missions. The trajectory is not periodic, ie. it doesn't repeat more than once. The trajectory around the earth takes less time than lunar period ("month") so when the craft goes back up, the moon has moved on. You might be able to construct a planet-moon system with an m:n resonance in the orbital periods of the moon and the craft so that the tracjetory is periodic.
Free return trajectories are used in manned space flight to guarantee that the craft and crew return to earth if a failure prevents from entering lunar orbit.
Very cool! I was able to get 2 masses to oscillate around each other in a funny way[1]. Seems they keep going like that forever. What is this kind of equilibrium called?
Isn't that a normal orbit around a common centre of mass? As the objects have a similar size the centre of mass appears to wobble as it moves along. In the frame of the centre of mass, the objects would just go round in standard orbits.
> Isn't that a normal orbit around a common centre of mass?
If you limit yourself to looking at the position of one body with respect to another, the orbit will be an ellipse. A circular orbit is simply a special-case ellipse with an eccentricity of zero. This is true for any two orbiting masses -- from the perspective of either of them, the other body's orbit will be an ellipse. And yes, it's always with respect to the common center of mass.
Interestingly, mostly because of Jupiter, the solar system's common center of mass can sometimes lie outside the sun.
Once you change references frames to the center of mass, two bodies that are gravitationally bound are always following ellipses. It looks like this in the case where they have equal mass:
> Likewise, two bodies that are not bound will follow hyperbolas
Or parabolas, which also represent unbound solutions. In an orbital system, a parabolic trajectory represents escape velocity (exactly), a solution in which the escaping body's velocity is in progressive decline, and that reaches zero at infinity.
Quote: "Particle mass is log of radius". Why not use real physics and make the mass proportional to the cube of the radius? It's also easier to compute. In fact, taking the log of the radius goes in the wrong direction -- the mass of a planet really does increase as the cube of its radius, which changes in a way opposite to log().
Oh, well. Here's my gravity simulator -- it uses JavaScript, no flash required:
They seem to have corrected the sentence now: "particle radius is log of mass".
Wow, your simulator is much nicer, plus a great article about it to boot! You should add an option to play cosmic billiard, that's probably the main appeal of the flash simulator :)
My point is that the two functions have a different behavior, the absolute values generated aren't very important compared to that. For solutions to f = G m1 m2 / r^2 where both bodies are computed, this will produce results wildly different than reality. (If only one body is computed, for example against a much larger parent body mass, the satellite mass stops making a difference.)
> You should add an option to play cosmic billiard, that's probably the main appeal of the flash simulator :)
Nice idea. I was more interested in portraying the solar system using real planetary masses and real physical constants. Still, it's a nice suggestion.
Great! I wanted to say that the "add random" button tends to shoot particles light-years away, never to be seen again. Is that what you were intending?
Question.. How big is the frame? I create two objects and they went out of frame. Then I create 2 more but a bit bigger ones and after 2-3 minutes I see those two objects coming back and it looks good too :D .. check it out http://imgur.com/IBYeysm
I don't think there is a "frame". It solves for all particles all the time.
After all, if a particle leaves the viewport, it doesn't affect the particle count readout at all.
I assume if things move far enough, there would probably be interesting floating-point precision errors, but I'd imagine that would take quite a while.
This is pretty cool! I wonder if there's a way I could implement that somehow into our turtle graphics app. Turtle gravity?
As for this app it would be awesome if you could zoom out -- I find most of my stable(-ish) orbits are very long and at very large mass sizes, so it would be good to see their entire orbits.
Would love a setting to select the number of objects to drop on click, and the spread for them ie (20 objects, 50px radius) and also for objects to gain the mass of objects that hit them, so that if a bunch of huge objects collide, they create a super-object
I did something similar on 3d but is not on realtime and generate outputfiles that could be ploted with gnuplot. It uses an third order Euler integration. Some day I should write a realtime mode for it:
Very cool. I notice that many ships tend to get stuck on the edge of the map though. Maybe make it so they loop back around to the other side of the map?
Thanks. Yeah, there are a couple of glitches in there. The ships bounce off the edge of the screen, and smaller ships run from bigger ones -- combined, that makes them crawl along the sides. Looping around is a good idea, or I'm wondering if there could be some kind of log scale to distance the further out from the centre the ships get. I did a variation a while back with a star in the middle that could be tweaked for that (click to add a ship). Mind you, the gravity from the star pretty much takes care of that problem.
If you're interested in learning some of the basics behind this kind of simulation I highly recommend the Nature of Code by Daniel Shiffman - lots of physics and programming fun.
Think about how breath-taking and educating must it be for a kid to write such a thing.
As a person who actually learned basic mechanics by writing video games I do believe that "you ain't understood nothing until you know how to teach it to a computer". Trying to express knowledge in (working) code is a great exercise that mercilessly catches even tiny holes in one's understanding.
Ditto that, I often tell people computers are very stupid. One proof of that is they let humans program them. The second proof is you have to teach them everything from scratch. :-)
Built something similar in C/GL a few years back. Quite a fun exercise, it only took a couple of hours to get the basics working. It has no collision detection, so particles that end up too close end up with infinite velocity, which is quite fun to watch.
134 comments
[ 4.8 ms ] story [ 223 ms ] thread> Particle radius is log of mass.
Wouldn't it make more sense for the radius to be the cube root of mass (assuming uniform density)?
> Error #2046
I did "rm -rf ~/.macromedia/Flash_Player/" but still get Error #2046....
[1] https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&c...
https://i.imgur.com/j3YwI5y.png
That was me trying to have a small particle making an 8-shaped path around two bigger ones that would be sufficiently far apart to not interact too strongly with each other. Of course, when the small particle went between the two bigger ones, it shifted their position a tiny bit, but sufficiently for those two to start very slowly moving towards each other, while the small particle was headed straight to the up-right direction. But when the two bigger particles became close enough to finally meet and become one single huge particle, it attracted back the small one, which since then goes back slowly to the huge particle only to shift it a bit and be "relaunched" by it for a new lap. The system seems to be totally stable that way.
Update: https://i.imgur.com/heHekdc.png
This kind of path is called a free return trajectory and was used in the Apollo program lunar missions. The trajectory is not periodic, ie. it doesn't repeat more than once. The trajectory around the earth takes less time than lunar period ("month") so when the craft goes back up, the moon has moved on. You might be able to construct a planet-moon system with an m:n resonance in the orbital periods of the moon and the craft so that the tracjetory is periodic.
Free return trajectories are used in manned space flight to guarantee that the craft and crew return to earth if a failure prevents from entering lunar orbit.
[1]http://imgur.com/FQYpo9V
That's the thing with those kind of simulators (or, actually, with reality), your reference has no relation to the center of mass of the system.
Of course, if you "were there" the reference would be the center of mass, like the reference of the solar system is "The Sun" (or a point inside it)
https://en.wikipedia.org/wiki/Barycentric_coordinates_(astro...
If you limit yourself to looking at the position of one body with respect to another, the orbit will be an ellipse. A circular orbit is simply a special-case ellipse with an eccentricity of zero. This is true for any two orbiting masses -- from the perspective of either of them, the other body's orbit will be an ellipse. And yes, it's always with respect to the common center of mass.
Interestingly, mostly because of Jupiter, the solar system's common center of mass can sometimes lie outside the sun.
http://en.wikipedia.org/wiki/Binary_star#mediaviewer/File:Or...
OP: This is an amazing tool to learn the sensitivity of dynamical systems to initial conditions. Well done!
https://en.wikipedia.org/wiki/Barycentric_coordinates_(astro...
Likewise, two bodies that are not bound will follow hyperbolas in the center of mass frame.
Or parabolas, which also represent unbound solutions. In an orbital system, a parabolic trajectory represents escape velocity (exactly), a solution in which the escaping body's velocity is in progressive decline, and that reaches zero at infinity.
It took a little bit to generate this one.
What do you need Flash for?
Oh, well. Here's my gravity simulator -- it uses JavaScript, no flash required:
http://arachnoid.com/orbital_dynamics
They seem to have corrected the sentence now: "particle radius is log of mass".
Wow, your simulator is much nicer, plus a great article about it to boot! You should add an option to play cosmic billiard, that's probably the main appeal of the flash simulator :)
> They seem to have corrected the sentence now: "particle radius is log of mass".
It's still wrong. Here's a graph comparing mass = e^radius (the reciprocal of radius = log(mass) ) versus mass = radius^3:
http://i.imgur.com/XkVFgIH.png
My point is that the two functions have a different behavior, the absolute values generated aren't very important compared to that. For solutions to f = G m1 m2 / r^2 where both bodies are computed, this will produce results wildly different than reality. (If only one body is computed, for example against a much larger parent body mass, the satellite mass stops making a difference.)
> You should add an option to play cosmic billiard, that's probably the main appeal of the flash simulator :)
Nice idea. I was more interested in portraying the solar system using real planetary masses and real physical constants. Still, it's a nice suggestion.
http://newton.azurewebsites.net/
Pure Javascript using Sylvester.js for Math.
Question.. How big is the frame? I create two objects and they went out of frame. Then I create 2 more but a bit bigger ones and after 2-3 minutes I see those two objects coming back and it looks good too :D .. check it out http://imgur.com/IBYeysm
After all, if a particle leaves the viewport, it doesn't affect the particle count readout at all.
I assume if things move far enough, there would probably be interesting floating-point precision errors, but I'd imagine that would take quite a while.
As for this app it would be awesome if you could zoom out -- I find most of my stable(-ish) orbits are very long and at very large mass sizes, so it would be good to see their entire orbits.
http://arachnoid.com/orbital_dynamics/
That's already what happens here.
https://github.com/Zardoz89/nBodySim
There are a couple of variations, and some tweaks like the ships accelerating perpendicular to the planets so they don't crash land.
http://codepen.io/simonswain/full/ftEjD/
http://codepen.io/simonswain/full/CeHmh/
I have a non-combat version in 3d. Now I know what mine is missing. https://www.youtube.com/watch?v=73O8aDN41sU
That's be a toroidal spacetime surface, wouldn't it? Would gravitational influence also have to "loop around" the borders?
If not, you might get some very interesting effects if a mass is near the edge of the map.
http://codepen.io/simonswain/full/cKejC/
http://natureofcode.com/
As a person who actually learned basic mechanics by writing video games I do believe that "you ain't understood nothing until you know how to teach it to a computer". Trying to express knowledge in (working) code is a great exercise that mercilessly catches even tiny holes in one's understanding.
EDIT: oh hey, I found a binary. https://www.dropbox.com/s/ihfqnzjaxhtskwt/Screenshot%202014-...
https://github.com/quarterto/Yay-Physics
His app is being used in schools.
There has to be a game in this somewhere...