# Creating a basic “fixed” solar system to host a 3D space travel simulation

I'm trying to simulate a virtual/imaginary "solar system" in software--just a hobby project for now. Unfortunately this has made me realize exactly how much math I've forgotten since college.

Complete accuracy isn't important, and I'm not looking to do anything sophisticated... no need for multi-body calculations, just a star and a planet will do. I just want something that a lightweight simulation or a game might do.

I'll have a configuration file with some basic starting parameters for each planet. At the start of the simulation, time=0 seconds, all planets would be lined up in a row (planning on just placing them on the same axis at their perihelion distance from the star). I'd like the planets to move around their orbits at the correct speed given the parameters supplied. So if I decide to set time = 1e10, I need to be able to calculate the x and y positions of each planet in their orbit at that precise time.

I'm flexible on WHICH parameters need to be provided. So if this becomes easier using some other method of defining the orbit, I'm open to it. Right now I'm thinking perihelion, mass, and time elapsed.

(Since this is a 3D simulation, eventually I'd also like to work inclination in, but I'm trying to start off simple for now, so inclinations will all be zero.)

Here's some sample parameter data below in case it helps provide a better example.

Star mass = 2.00e30

Planet mass = 3.30e23

Planet perihelion = 5800000

(Ex. Where would this planet be, in X/Y coordinates, at time=x?)

If someone posts a formula I can just plug in I won't complain. But if I could just be pointed in the right direction for what to learn or refresh my memory on, I'd like to try and figure this out myself. So far I've been looking at Kepler's 3rd Law equations but I'm not sure if that's a good place to start. Feeling a little guilty that I seem to have forgotten virtually all math I learned in college just over a decade ago, and I kind of want to reverse some of that decay. Hopefully this makes sense!

• How about this answer on stack overflow? The code in there might give you an idea to get started. (Basically a first loop to calculate the total gravitational forces on each object, and a second loop to calculate the change in their positions over the next time slice.) – Andy Sep 20 '16 at 6:16
• This article on wikipedia gives a few hints on where to start. If you want to add in some complexity, this course page from Princeton is useful. – Reuben Mallaby Sep 20 '16 at 8:26
• Those resources are useful, but in essence, your answer is just links. Consider to flesh it out a little, or make it a comment instead. Oh, and by the way, welcome to this part of the SE network. – SE - stop firing the good guys Sep 20 '16 at 11:44
• Not worth a full answer, but just for reference, an orbit requires 6 parameters to uniquely define it. You might want to set up your input file to use all 6 to begin with, but zero out anything you don't need or understand initially. You'll definitely need to start by defining the semi-major axis (in place of perihelion, although perihelion could technically work as well) and the eccentricity (equivalent to defining the energy of your orbit). – zephyr Sep 20 '16 at 13:02
• If you had an initial velocity vector for the planet, you'd have enough to start the simulation. As @zephyr notes, this would be a basic elliptical orbit. Adding a third body would make things a lot harder, since you'd now have the "three body problem" which has no closed form solution. – user21 Sep 20 '16 at 17:06

The easiest approach is to do a numerical integration of the equation of motion of your system. For that you need to remember that the gravitational force of $a$ on $b$ is $$\vec{F}_{a\rightarrow b} = -G\frac{M_a M_b}{r_{a\rightarrow b}^{3}} \vec{{r_{a\rightarrow b}}}$$ where $\vec{{r_{a\rightarrow b}}} = \vec{x_b} - \vec{x_a}$ and that $$M\vec{a} = \sum \vec{F}$$ where $M$ is the mass of your object, $\sum\vec{F}$ is the sum of the forces applied to the object and $\vec{a}$ is the acceleration.

To do the simulation, you then have to follow this numerical scheme

1. set some initial conditions to your problem: initial position $\vec{x_p}$ of the planet and $\vec{x_\star}$ of the star and initial velocities $\vec{v_p}$ and $\vec{v_\star}$.
2. compute the force $\vec{F}$ of the star on the planet and the accelerations of the planet and the star: $$-M_\star \vec{a_\star} = M_p \vec{a_p} = \vec{F_{\star\rightarrow p}}$$
3. update the speed of the planet and the star using the respective acceleration: $$\vec{v}(t+\Delta t) = \vec{v}(t) + \Delta t\times \vec{a}$$
4. update the positions of the planet and the star using their respective velocity: $$\vec{x}(t+\Delta t) = \vec{x}(t) + \Delta t\times \vec{v}$$
5. recompute the distance between the planet and the star $\vec{r_{{\star\rightarrow p}}} = \vec{x_p} - \vec{x_\star}$ and go back to 2.
• This is the way physics simulations work. Of course, you can always get more involved and use "smarter" math. What is presented here is a simple Euler method for approximating the future evolution of something. As you get more into this, you might look up more robust methods like Runge-Kutta. Depending on your language, there's likely an implementation of the math behind these methods already set up so you just plug and play. – zephyr Sep 20 '16 at 12:59
• Oh, but a simple method is exactly what I need. Will take the time to fully understand this, as I should have been able to figure this out alone, but maybe next time. Thanks for the help with this (site isn't letting me up vote anything). Language is Java. – User Sep 20 '16 at 21:52
• There is no need to do this, as planets move in circles; and the above math would be beyond the requirement. The OP is simply showing a diagram representation of a planet going around a star. There is no "simulation" involved whatsoever. (It's inconceivable the OP wants to start doing finite element analysis, or the like!) – Fattie Sep 23 '16 at 16:28
• Note that I have boldly removed the word "simulation" from the question, using an edit suggestion, since that is absolutely no what the OP wants. Perhaps it will help clarify the situation. – Fattie Sep 23 '16 at 16:34

(choose "Helios" button, top right)

As an "incredibly rhetorical" question, heh, can you see any ellipse-ness in the planets orbits? Your ultimate game result would, I imagine, look something like that webapp. The pink/orange lines showing the transfer of the two (real) spacecraft Earth to Mars would I guess be something like in your game.

I would just reiterate that literally for a game, or any conceivable "display of a planet system", all you have to do is "draw a circle" and "put a dot on it which moves around in a circle". Making game-like displays of planet system is remarkably easy - since the scale is so tremendously large, heh!

(Again you can simply get the year-length from the trivial formulas linked below, remembering you have to drastically alter timescale.)

Hope it helps!

Just for the record:

To create a moving diagram showing planet(s) orbiting:

(1) as you say, place them at the desired distance and know the mass. (2) calculate the "year" length of time.

(It is trivial to do that with, as you say, Kepler's equations. Easily found, example: plug-in equations.)

Of course, you'll scale time. (What about 1 Earth-year is one minute?) (Indeed, you will of course have to radically scale-up the body sizes, or you will simply see absolutely nothing.)

I had a window open so I just did this in a game engine; it takes 7 clicks and 3 lines of code!

Note: you mentioned "simulation" in your original question. That term has a specific technical meaning (especially to anyone on this site), and it is utterly unrelated to what you are asking. Enjoy!

FTR I gather from your other question you want to show extreme "video game like" ellipses. Purely as a matter of interest, for your information the way you literally do that for literally a space-travel-like game (whether app or PC) is either

(a) trivially, just have the planet move in and out (whatever percentage you want) each half-year. (simply use a separate transform, so there's a transform for it going around, and a transform for it going in and out) or

(b) nudge it as outlined for example here, using sin and cos (Or, all game engines or graphics/animation apis have a "ping pong" and/or "smoothing-at-ends" call, just use that.)

A reminder that your display will be drastically altered from reality since you will be presenting 10 or 20 months in, say, 10 or 20 seconds.

• Well hold on now, I agree I didn't phrase the question technically perfectly, but the overall goal is to do what I'd still call a basic simulation. I didn't elaborate on this aspect, but I do want to "simulate" (in a more technical sense than a simple math plot) space vehicle travel within this system. Also keep in mind the fantasy element - I might have very eccentric orbits (which might technically be unstable over a long period). I do want technical terms like perihelion/aphelion to be meaningful too, so this goes a bit more towards "faking it" than I'd like (I do still want ellipses). – User Sep 26 '16 at 20:46
• You wouldn't have the computing resources, or the engineering department, to do finite element analysis. By all means use the word "simulation' as you wish but as I typed above: "That term has a specific technical meaning (especially to anyone on this site), and it is utterly unrelated to what you are asking" Enjoy! – Fattie Sep 27 '16 at 3:15
• That's why I'm using terms like "crude" simulation (I still think it conveys my intent well enough taken in a casual context); obviously I'm not looking to put JPL out of business. I mean, thanks for the help and suggestions, but I think you're being a little too technically strict with the term to a point that it seems a little unfriendly towards amateurs. I thought I made it pretty clear that I'm not doing something that requires a team of 20 people and a supercomputer. I think your suggestion is probably a good solution, but I hoped to support elliptical orbits at least. – User Sep 27 '16 at 3:33
• The problem here is that orbits are ellipses, not circles. It takes more than 3 lines of code. – ProfRob Sep 28 '16 at 9:16
• For sure - like I mentioned in a comment, as far as you can represent on a monitor it's just a circle (I thought the OP was doing an our-solar-system-like diagram - I hadn't seen the OP's other question showing extreme "arcade game" ellipses.) – Fattie Sep 28 '16 at 10:30

You don't need to do a physics simulation to do what you want. Kepler's laws of planetary motion will do just fine and they account for elliptical orbits of course.

You will have to do a bit more Maths if you want your orbits to be elliptical. The Maths you need is summarised here. This is a recipe for calculating $r$ and $\theta$ as a function of time, where $r$ is the helio(astro)centric distance and $\theta$ is the true anomaly, which is the agular coordinate at that point of time. In turn you would have to specify the mass of the star (and planet if it was significant), the orbital period (or semi-major axis), the perihelion(astron) position and the position at $t=0$.

The orbital inclination is independent of these calculations, since in this basic scheme there is nothing to alter the angular momentum of the orbit and so there is a fifth parameter defining that.

The calculations are reasonably simple though you will have to do something numerical (like the Newton-Raphson method) to get the eccentric anomaly in step 2.

If you wish to start taking 3-body (or more) interactions into account then you will have to think about physics simulations. I think the scheme given by cphyc will work ok so long as you make the time step very small and don't integrate over many orbits. If you are interested in the stability or long term evolution of planetary systems that you setup then you will have to get into much more complex schemes, since the one suggested by cphyc is numerically unstable.

• Ooo that might be exactly the math I need - "as a function of time" - didn't notice it before! – User Sep 29 '16 at 20:36