Orbital mechanics simulator in Flash

Strange... today on another computer the sim runs fine. It was Flash player 9 instead of 10.
Hmm... well, any amount of lag can through a program like this off. Unless the trajectories are based on time, more lag results in more incorrect movement. So if the other computer and player were ever slow or jerky, that might have been the/a problem.
 
The computer I used to make the second screenshot was actually slower than the one used to make the first screenshot (the messed up one).
I tried this on my computer again, and added some junk looping code somewhere to slow things down. Result seemed to show that the orbits change less dramatically.

Another strange thing: the middle planet only moves either horizontally or vertically but never diagonally.

EDIT: Updated file. http://contland.110mb.com/perso/ob/test2.swf (the link is weird, you have to copy paste it, not click on it)
- Runs at 120fps (meaning code runs 120 times per second and updates the image 120 times per second), may be unsuitable for low-end computers.
- The rock on the left is disabled for the moment.
- The middle planet's mass is 10^16kg, and the rock's mass is 1kg.
- Initial distance between them is 250m (VERY close! Maybe too close).
- The initial velocity vector of the rock is 0m to the right and 50m down.
- The path lines redraw after 7200 frames which should mean 1 minutes but is actually around 5-10 minutes depending on computer (clear some memory).
- Some debug info is available.
Now the orbit seems much more stable.
Maybe the thing that went wrong was just the "universe configuration". The middle planet was too "light" and the distances were too close so that even a 1kg rock could pull it slightly.

What's left to do is to rework on the displaying, like to add the ability to zoom in/out, so that I can make greater distances work. Calculating the timesteps stuff might also be something to consider.
 
Last edited:
http://contland.110mb.com/perso/ob/
Just updated it again (test20090504_x.swf).
Basically just code structure updates.
- ADD: ability to zoom and pan (only inside the code though, no buttons, so you can't really control it).
- FIX: simulate more than two objects at a time correctly.

test20090504_1 is an attempt at making binary star systems. test20090504_2 is similar but there's a star in the middle.
 
http://contland.110mb.com/perso/ob/
Just updated it again (test20090504_x.swf).
Basically just code structure updates.
- ADD: ability to zoom and pan (only inside the code though, no buttons, so you can't really control it).
- FIX: simulate more than two objects at a time correctly.

test20090504_1 is an attempt at making binary star systems. test20090504_2 is similar but there's a star in the middle.

It looks like the drawn path is coming from an edge of the circle? I think it would make more sense for it to be coming from the center...
 
I'll have to fix that. It's currently drawn from the top-left corner (the "0,0" position).

The distances are now in the range/magnitude of around 10^3 and 10^4 meters.

Is there anything wrong with the orbits of the binary "stars" in test20090504_1? These orbits shrink inwards everytime and they behave like this until both "collide" (both get ejected, since there is no collision detection here). Is this what happens normally with binary stars?
 
It looks like the drawn path is coming from an edge of the circle? I think it would make more sense for it to be coming from the center...
Yeah, he probably defined the center of the circles as the top-left corner in Flash. At least in my (old) version of Flash, there is an option to change where the center is. (or you could simply go within the circle movieclip's level and move the actual shape) Since the calculations are probably for the point where the line is being drawn, it'd be better to move the circle than move the line.

EDIT: lol. cr1 beat me, himself. ;)

Also, I think the reason that the binary 'stars' collide is probably because they have orbits that are too eccentric to be stable. It's probably accurate though.
 
For the next update (maybe tonight) I'll fix that line drawing thing as soon as possible, should be easy (thanks Quick_Nick ;)). I'll also try implementing a time-step system instead of the current "run this code 120 times per second" system, and buttons to pan and zoom.
The binary star scenario will be fixed in a way to make orbits less eccentric...

And, any idea how to implement an accurate enough time acceleration?

EDIT: Just found http://gafferongames.com/game-physics/fix-your-timestep/ and http://gafferongames.com/game-physics/ , might be helpful
EDIT2: One of the links above seem to make me do Runge-Kutta stuff... Ouch, I may need lots of help here.

---------- Post added at 03:26 PM ---------- Previous post was at 01:19 PM ----------

For those who know Flash (better than I do), is there a better way to draw the orbit lines? Currently I'm using the MovieClip.lineTo(x,y) method 120 times per second and that seems to slow down things a lot after a while.
(Hope this double-post is merged)
 
Last edited:
EDIT: Just found http://gafferongames.com/game-physics/fix-your-timestep/ and http://gafferongames.com/game-physics/ , might be helpful
EDIT2: One of the links above seem to make me do Runge-Kutta stuff... Ouch, I may need lots of help here.
I just happened to be looking over some Runge-Kutta info lately. :) I was going to put it in my Java orbit program but I was sick at the end of last week (flu?) so I haven't bothered with it yet. I may do that soon.
Anyways, RK is easier (or so I think :lol:) than it generally looks. It's just running a function multiple times with different input variables and doing simple math on the results. (and I THINK that the 'function' is more or less just the math that you normally do each frame)

For those who know Flash (better than I do), is there a better way to draw the orbit lines? Currently I'm using the MovieClip.lineTo(x,y) method 120 times per second and that seems to slow down things a lot after a while.
(Hope this double-post is merged)
I don't know any better way. The only ways I know to speed things up is to put fewer lines (remove lines that have a certain 'age') and/or to set quality to low. In this program, if you set the quality to low, image quality isn't lost but the program speeds up a LOT.
 
http://contland.110mb.com/perso/ob/
test20090506.swf update:
- FIX: Lines now draw from the middle of the "planets" (not visible here because the lines are disabled)
- ADD: keyboard control and zoom buttons for controlling the viewport, and zoom buttons
- SCENE: includes 1e16kg mass in the middle, two 1e12kg masses orbiting it at 2.5km initially, and a small light-green 1kg mass 70m from the dark green mass.
- CHANGE: Rewrote some parts of the code to transform x and y (position and velocity) variables into one "Point object" (like a vector) containing both variables and some other useful functions
- CHANGE: Line paths are disabled for the moment because if you move the viewport the lines get screwed up
Timesteps are not integrated yet.
I'm trying to make the light-green mass orbit the dark-green one (seems like I failed this attempt).
For the next update there may be a time-step system, viewport displacement buttons and an option to "dump out" information about the current simulation. Maybe also buttons to toggle between Low, Mid and High Quality, and more viewport control options. The zoom system screws up the masses' diameter (they stay the same at the different zoom levels) so I'll also fix that. I'll leave RK for later :D

The simulation runs extremely slow on one of the computers I tested it on (even in Low quality)... How fast is it on yours?
Feedback is welcome.

@Quick_Nick: Swine flu?

EDIT: Near frame 18800 the light green ball gets ejected... :(
 
Last edited:
Is the center object affected by the other objects? It really needs to be.
Anyways, the speed is fine for me. (although Low doesn't speed up anything :P)

(lol. I assume it wasn't swine. It only lasted a few days and was mild (although swine flu is now said to be mild). Plenty of people at school have been sick but no one has been diagnosed with swine flu. (although it's likely that no one ever went to the doctor :P))
 
Quality setting doesn't affect the speed at all, as expected. Not much to draw anyway.
Oddly enough, the simulation speeds up considerably when the right click menu is open...
 
The central planet is affected, except that the distances are too great.
Remember F*m1*m2/r^2, the distances here are in the range 1km-3km, the mass in the middle is 10^16kg, and the two planets are 10^12kg, thus the acceleration rarely exceeds 10^-3m/s^2.
Meanwhile I'll try to understand what's happening with the sim speed. Maybe integration of a proper fps-independent time-step system might solve the problems.

EDIT: On my computer the sim slows down considerably with the right click menu open.
 
Last edited:
http://contland.110mb.com/perso/ob/
test20090506B.swf update:
- ADD: A scale to indicate some distances (screen bottom-left)
- ADD: FPS and zoom indicators (screen top-right)
- ADD: Quality toggler (screen bottom)
- CHANGE: Viewpoint displacement arrow buttons now enabled (screen bottom-right)
- FIX: Zooming in and out is now based on the center (indicated by the grey cross), not on the top-left corner like before
- SCENE: Finally made a successful "moon", except that near frame 5000 the whole sim goes "wrong" and the red planet+moon gets ejected. The "Sun" is 1e16kg, the "planets" are 1e14kg, distances are same as before. The "moon" is 1kg and initially 100m away from its "planet".

Sometimes after zooming out, the masses that get ejected are not visible anymore, I'll try to fix that.
Quality change doesn't seem to speed up the sim.
For next update I might make the long-announced time-step thing, and change the scene so that the distances are much greater than they are right now.

Meanwhile does everything still seem normal?
 
It works like a charm. The FPS readout is pretty useless on a fast machine, at least here it seems to jump between 500 (max?) and some sub-100 numbers. It is just too damn fast to get a proper readout.
 
Thanks for your feedback
Currently FPS updates itself every 3 frames, maybe thats too often... The sim is set to run at 120 fps. Maybe I'll make it update every 60 frames so it doesn't become too jumpy.
 
Cool! On my (old) computer I get about 63 or 67 FPS. (it alternates) Cool explosion of planets. ;) And yay, they actually scale with zoom now! :) I'll try it on my (new and nice) Vista later.
Keep it up! ;)
 
Haha thanks!

http://contland.110mb.com/perso/ob/
test20090507_epicfail.swf:
Tried to implement: time-step control.
Result: epic failure.

test20090508.swf update:
- ADD: Should have a correct but very basic time-step control system.
****... forgot to upload it... :(
Wait for another 5 hours until I get back home <_<

EDIT: Keyboard arrow buttons don't seem to work anymore, and the on-screen buttons are buggy. Gotta fix that.

---------- Post added at 08:03 PM ---------- Previous post was at 11:03 AM ----------

Uploaded 20090508!
Nothing special... but at the very least my time-step system works! :D
 
Last edited:
http://contland.110mb.com/perso/ob/
test20090510.swf
- ADD: Basic time-step control (no RK yet). Very basic time acceleration is included, though it's not recommended to go above 200x unless you want to screw up things. Negative time acceleration also possible. Maximum limit is 240x both ways.
- ADD: Simulation can be paused.
- ADD: Zoom scale is now "draggable", so it can be used as a ruler to measure distances.
- ADD: Keyboard shortcuts: "Numpad +" to zoom in, "Numpad -" to zoom out, arrow keys to move, time acceleration keys as in Orbiter ;)
- FIX: Keyboard arrows now work again.

Feedback please, and any bug reports will be very welcome.

(sorry for the double-post)

EDIT: http://gafferongames.com/game-physics/fix-your-timestep/ tells me to decouple the physics calculations from the render engine, so that the physics run at a certain fps and the rendering at another fps. Is that what's happened to Orbiter and the Visualization project? And, how should I implement that in Flash, where everything should be running at the same fps?
 
Last edited:
It's looking very nice! I'm not sure if there's much left for me to say about it. :P
I wouldn't try to seperate fps in Flash. Just run it all at preferably high FPS for more accurate physics. Graphics will take care of itself in Flash. If this were a more complex program in a different language you might run the physics at as high an FPS as possible and only display graphics at about the screen's refresh rate. That would decrease load on the system since it wouldn't waste time running the display code on every frame. I don't think that's necessary here.
 
Back
Top