7
$\begingroup$

I've been developing a planetary simulator in Unity 3D (C#) and I need some help, however I feel this would be a better place for it. I'm starting my planet from a position vector. On initialisation I apply a direction vector, which puts it into orbit around a larger star. The orbits aren't circular, and I'd like for them to be elliptical.

I've read up on foci, the semi-major axis and semi-minor axis, on several laws by Newton and Kepler, I understand the apoapsis and periapsis, and yet I just can't figure out what I need to do. What I've done is leave a trail from the planets, and the orbits can be seen. (note: I know the layout of planets aren't correct!)

planets

It looks nice, but it's not what I wanted. I'd like to be able to predict the orbit. I've found equations so I can calculate the sphere of influence, which require the semi-major axis. I could calculate the semi-major axis if I had the orbital time, and I could calculate the orbital time if I had the semi-major axis. However I only have an initial position, a vector force I apply to it, the distance between the planets, and also the masses of each. I'm at a dead end here, I'm not sure what I'm looking for. Could anybody please give me some pointers (or formulae) in order to do what I'd like to do.

I'd really appreciate any help, thanks in advance!

Improve this question
$\endgroup$
3
  • 1
    $\begingroup$ What, exactly, do you mean by "initial direction vector"? If it's what I think you mean (the unit tangent), you can't "predict an orbit, based on an initial position and an initial direction vector." The position vector has three degrees of freedom, but the "initial direction vector" only has two. Whatever scheme one uses to describe an orbit (and there are lots of them), six independent parameters at a specific epoch time are needed. You only have five. $\endgroup$
    – David Hammen
    Commented Jul 6, 2015 at 22:59
  • $\begingroup$ possible duplicate of Determining orbital position at a future point in time $\endgroup$
    – 2012rcampion
    Commented Jul 8, 2015 at 4:49
  • $\begingroup$ I worked for a few months on a game/simulation, and eventually had to give up on the idea of doing anything mathematically elegant. I could use Kepler's laws for orbits, IF you assume the planets have no effect on each other. For planets, that's fairly correct, but less so for satellites, and much less so for spaceships. I had to go with Newton, and do a purely iterative approach. Slice time up into small enough segments, and calculate all forces on each object each increment. Simple, but you can't predict where anything will be in the future without calculating every moment in between. $\endgroup$
    – Ask About Monica
    Commented Jul 13, 2015 at 17:25

3 Answers 3

Reset to default
11
$\begingroup$

In three dimensions you need six numbers. What you are asking about is how to convert from one set of six numbers, three position coordinates and three velocity components (note that simply direction is not sufficient), to another set of six numbers, the six orbital elements.

I'm not going to give you the equations, but I'll get you started. You can google the equations. First compute the energy, a scalar. That will tell you if it even is in orbit (negative energy) or hyperbolic (positive energy). From the energy you can readily compute the semi-major axis. Then compute the angular momentum vector. The direction of that vector will tell you the plane of the trajectory and the direction in that plane (that vector is perpendicular to the plane of the trajectory). Then compute the eccentricity vector. That vector will lie in the plane, and will point to the periapsis or closest approach for a hyperbola. It's magnitude is, of course, the eccentricity of the orbit or hyperbola.

Then you'll have all you need to generate the orbital elements.

Improve this answer
$\endgroup$
5
  • $\begingroup$ I've found some equations, and they reference using G... strangely enough in my simulation, I've not used G... I've simply done F = (m1*m2)/d^2. When I substitute it in, it just flies off and doesn't pay attention to the orbit. $\endgroup$
    – Jacob Morris
    Commented Jul 6, 2015 at 19:23
  • 5
    $\begingroup$ What you will usually see is the combination $GM$ of the central body, sometimes shortened to $\mu$. In the real world, we never use $G$, because we can measure $GM$ much more accurately than either $G$ or $M$. $\endgroup$
    – Mark Adler
    Commented Jul 6, 2015 at 19:39
  • $\begingroup$ I'm having some problems with calculating the semi-major axis. First of all I calculated the orbital speed (so it can be plugged into the other equation). I used $v = root(M/r)$. Then I calculated orbital energy with $e = v^2/2 - (m1 + m2)/r$. I then used the equation $v^2 = (m1+m2)(2/r - 1/a)$, and rearranged to find a, the semi-major axis. However the length changes length as the planet orbits... Any ideas why it's doing this? $\endgroup$
    – Jacob Morris
    Commented Jul 6, 2015 at 21:10
  • 1
    $\begingroup$ First, you need $G$ in front of all the $m$'s. Second, your equations result in $\mathcal{E}=-{\mu\over{2 a}}$, from which you can get $a$. $\mathcal{E}$ is a constant of motion, so you would compute the same value at every point in the orbit. (Do not use $e$ for the specific energy since that is the symbol for eccentricity.) $\endgroup$
    – Mark Adler
    Commented Jul 6, 2015 at 22:08
  • 1
    $\begingroup$ By the way, if you are assuming $v=\sqrt{\mu\over r}$, then you are assuming a circular orbit. Then $r$ does not change, and $a=r$. $\endgroup$
    – Mark Adler
    Commented Jul 6, 2015 at 22:41
2
$\begingroup$

This JPL/NAIF SPICE toolkit routine OSCELT answers what appears to be a query about the two-body problem.

N.B. I assume your "direction vector" is actually a "velocity vector;" the STATE input to OSCELT is a six-element vector that is the the concatenation of the position and velocity vectors.

N.B. as noted above you do need a seventh number: MU, the GM value for the central body.

Technically you also need an eighth number, the time of the initial conditions, to have a starting point to calculate future (and past) ephemerides.

That link is for the FORTRAN version of the SPICE toolkit because that is what Google returned first. There are also C, IDL, Matlab, Java and even informal Python interfaces for SPICE; making a DLL of the C-version that can be called from C# should be possible.

I won't make this any longer than it has to be: poke around the SPICE pages; SPICE has a steep learning curve but is worth the effort. The documentation is about the best you will find anywhere, or contact me for more details.

Improve this answer
$\endgroup$
0
1
$\begingroup$

Forgive my lack of a concrete answer, but it really depends on how accurate you need to be. I once wrote a simulator that used an n-body Newtonian approximation. It was nice, but not particularly well-implemented and could only support a couple dozen bodies before it slowed to a crawl.

KSP uses a simpler, more scaleable approach; a spaceship is only attracted to the body who's sphere of influence it inhabits, and planets and moons are on rails. This is a close enough approximation for a video game, and it doesn't grow out of control as you add more objects to the simulation. The tradeoff is that it means you're only ever attracted to one object at a time, so you don't see Lagrange points or other interesting gravitational effects.

Even a well-implemented Newtonian n-body model would be far more computationally expensive than KSP's system, and still wouldn't tell the whole story, as Newtonian physics doesn't take relativistic effects into account. (If you think relativistic effects don't matter to orbital mechanics, read up on the planet Vulcan: https://en.wikipedia.org/wiki/Vulcan_(hypothetical_planet))

It might be worth asking this question on Game Development stack exchange, as deciding how to best approximate an orbit has as much to do with the kind of game-play you want and the practical limitations of available computing hardware as it does with the physics of orbital mechanics.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ OP never mentions this is for a game, or that computational intensity is a problem. Actually, from reading the question, I get quite the opposite impression, that his planetary simulator is now developed to about the precision of an orrery but would like to simulate future orbits of arbitrary objects more precisely by inputting their ephemerides. TL;DR I highly doubt that simplified kinematics like KSP uses would do. $\endgroup$
    – TildalWave
    Commented Jul 6, 2015 at 22:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.