My orbits don't look like KSP

Questions & Answers
1

I’m trying to make a simple arcady orbit simulation with tiny planets that have Earth-like gravity. To do this I simply apply a force in the direction of the planet to all of the rigidbodies. As far as my understanding goes there is no reason this shouldn’t work. And yet, while everyone who has played KSP knows that orbits should have a single periapsis and apoapsis(low and high points), my cubes think they should have two of each and also sort of rotate their entire orbit a bit each flyby.
I’m hoping someone here can tell me what I’m doing wrong here and what I should do to get the expected result. I made a video:

Here’s the part of my code where I apply the gravitational forces to all rigidbodies in the scene.

private void FixedUpdate()
    {
        // apply gravity to rigidbodies from all gravitaional bodies they are in range of
        for(int i = 0; i < rbs.Count; i++)
        {
            for(int j = 0; j < gravBs.Count; j++)
            {
                if (Vector3.Distance(rbs*.transform.position, gravBs[j].transform.position) > gravBs[j].sOI)*

continue;
else
{
// dist from rigidbody to gravbody surface
float gravPull = Vector3.Distance(rbs*.transform.position, gravBs[j].transform.position) - gravBs[j].surfaceRadius;*
// percentage of gravity to apply (should be a number between 0 and 1)
gravPull = 1.0f - (gravPull / (gravBs[j].sOI - gravBs[j].surfaceRadius));
// final gravitational acceleration to apply to rigidbody
gravPull *= (gravBs[j].surfaceGravity * 9.80f);
// apply the force
rbs.AddForce((gravBs[j].transform.position - rbs_.transform.position).normalized * gravPull);_

// just to see how much gravity is being applied
rbs*.GetComponent().gravity = gravPull;*
}
}
}
}

2

Well, there are several things you have to clear up first. First of all do not base your knowledge of orbits on other games. Second your whole equation doesn’t seem to make much sense and does not look like it resembles Newtonian gravity, at all. All your “surface” references doesn’t make much sense and you scale your gravity linearly by the distance. Actual gravity scales with the quare of the distance.

The actual gravitational force is

F = G * m1 * m2 / dist²

However the resulting acceleration for a body is a = F / m. That’s why the attacted mass is irrelevant for the acceleration. If you plugin the values

F_body  = G * m_center * m_body / dist²
a_body = F_body / m_body

a_body = G * m_center * m_body / (dist² * m_body)  //-->
a_body = G * m_center / dist²

As you can see the mass of the body doesn’t matter as it cancels out. In the case of an object close to earth, m_center is the mass of the earth and “dist” is the distance from the earth center. On the surface that’s about 6000 km and gives us our famous acceleration of 9.81 m/s². However further out that value is significantly less. Keep in mind that the acceleration scales by the square of the distance from the center. So at double the radius it will be only a quater.

Yes, on the surface or very close to the surface the acceleration doesn’t really change much. Most things we care about on earth happens within say a 12km range above ground If we take the average earth radius (6371 km) and plug it into the formula we get 9.8196 m/s². If we add 12km we get an acceleration of about 9.7827 m/s². So only a tiny difference (0.037m/s² less)

Of course on a planetary scale distances get much larger therefore you really should use the distance squared properly.

However the fact that you see an eliptical orbit that is in itself rotating around the sun / center is just a matter of fact that you’re doing a time discrete integration simulation. This will never give you an accurate result. The real world does not run in discrete time steps but performs actual continous integration. Increasing the simulation steps per second would help to mitigate the issue slightly but your orbit will always drift when doing this. Many orbit simulations work with the derived orbit equations where you define your orbit based on the initial condition / changes and if no external force is applied we just follow our calculated orbit.

While calculating such an orbit is not rocket science, it is actually part of it and naturally not that easy ^^. Here are a few sources which might help you out

The real question is what do you want this orbit for and what level of accuracy do you aim for?- Note that even when using the right forumlas due to floating point errors a simulation won’t be “100% correct”. When it comes to actual orbits there are so many things that has to be accounted for. While still in the athmosphere there’s drag / air resistance. All objects in a orbital system rotate around the center of mass, even the largest “center” object. If more objects are involved this gets infinitely complex. Those changes are tiny but still have a small effect, especially over time. So again it highly depends on what your goals are.

Games in general do not really need to be physical accurate. In fact PhysX (which is used by the Unity engine) is in itself not physically correct. It’s just a simulation that is fast and very close to common needs where the errors are usually small enough so you won’t notice. For example PhysX does not perserve the angular momentum as it true in actual physics. Instead it will just preserve the angular velocity. This makes the simulation much simpler but certain things are impossible to simulate with such a system. Like the tumbling effect mentioned here in the middle bottom figure. Because this never happens in Unity we can not use this physics system to simulate things like a kickflip of a skateboard properly without a massive amount of workarounds. Most physics systems for games are build to give you a good approximation and to be efficient.