RigidBody2D with Area2D gravity - Initial velocity for a circular orbit

rknepp

First post. Be gentle.

I have 2 RigidBodies (Star is Static and Planet is Character)
Both bodies have Area2D with Combined Gravity points.
Global gravity is disabled.
More planets could be added and the idea is for each to Combine their gravity with the Star to give a n-body-like effect.

But for now I have 1 Planet to orbit around the Star.

During startup I want to set each Planet's velocity so that it is in a perfect orbit around the sun (ignoring for now the fact that each planet will interfere during n-body calcs).

However when I attempt to calculate the velocity required for circle orbit I find that the velocity is waaay to low to keep the planet moving in circle. This results in the planet plunging into the star.

I think I'm missing something obvious - here is current code in my ready function:

` func _ready():

    # set initial estimated veloc for each planet based on distance to star
    for member in get_tree().get_nodes_in_group("planet"):

        print("\nmem  ",member.name)
        print("sm  ",$Star.mass)        
        print("pm  ",member.mass)       

        # http://orbitsimulator.com/formulas/vcirc.html

        var direction = member.position.direction_to($Star.position)
        print(direction)

        var distance = member.position.distance_to($Star.position)
        print("dis  ",distance)     

        var dir_tangent=direction.tangent() 
        print("tan  ",dir_tangent)

        var bigG = 6.6743 * pow(10, -11)  # does this need tweaked?
        print("G   ", bigG)     

        var mag= sqrt((bigG*($Star.mass+member.mass))/distance)  # m/s
        print("mag  ", mag)     

        var accf=(bigG*($Star.mass+member.mass))/(distance*distance)  # not used currently
        print("acc  ", accf)        

        var velo=dir_tangent * mag  #  * 4000000    # seems that multiplying by about 4mil gives me almost a circle orbit
        print("velo ", velo)        

        member.linear_velocity=velo `

Fumbling with this for a few hours I noticed that if I multiply the MAG by about 4,000,000 then I get the (almost) circular orbit... something tells me that isn't the right way to handle it and that probably won't work for just any distance.

Please let me know if I can add more details.

What am I missing?
Am I misunderstanding unit conversions (pixels to meter?)
Is the gravity Acceleration Force even needed in this calculation?
What role does the Gravitational constant play here and if that needs tweaked how would I do that so that it works for planets at varying distances?

Godot version v3.3.3.stable.official [b973f997f]

Megalomaniak

cybereality I'm not sure about the calculation, but a power of -11 is pretty small (and you take the square root right after). You might be dealing with accuracy issues with floating point numbers.

rknepp Godot version v3.3.3.stable.official [b973f997f]

You might want to consider using godot 4 custom built with the doubles support. It might make things a little easier for you. But you should also keep in mind that it is still in alpha and breaking changes can still happen.

cybereality

I'm not sure about the calculation, but a power of -11 is pretty small (and you take the square root right after). You might be dealing with accuracy issues with floating point numbers. It would work better if you keep the numbers at reasonable magnitude and then just adjust at the end (right before you apply the velocity) to tweak it to your desired speed.

Also, note, you don't have to (and probably don't want to) use physically accurate numbers. Consumer computers are not good enough to simulate a universe with any sort of accuracy. So you are better off finding plausible approximations that still look believable.

DaveTheCoder

cybereality Consumer computers are not good enough to simulate a universe with any sort of accuracy.

But ... but ... our phones have more computing power than the computers used for Apollo 11.

Pixophir

Not only is the gravity constant 6.6.. * 10⁻¹¹ pretty close to 0.0 (that's what it prints) but also are other numbers very big. There will be heavy precision problems, to a degree that results won't fit in the 7 or 8 digit precision of a float.

n-body gravity needs really heavy math, one can find solvers out there, but these things don't have exact solutions and with the wrong tools movement becomes chaotic. Even with the right tools movement can only be approximated so far (decades, centuries). Question could be if such a level of realism is really desirable for a game. KSP for instance doesn't do it, it puts the planets "on rails" in a miniature solar system.

A suggestion for a simple approach for a scene 'Solar System Overview' could be:

using circles simplifies a lot (ellipses are a whole other class)
inclinations (3D) are optional, won't complicate too much
leave mutual disturbances away, can't control them in real time on a game engine
for each planet do calculations in -1..1 space sun in the centre. use a scale of 1/1million (even then there may be precision problems)
on startup, get the scaled radius of the orbit and the time for one full revolution. Edit: hand wave the value or pre-calc orbital speed v=sqrt(G)*M/r offline with a calculator that has a higher precision and use the value as a constant in your program.
as time ticks off, trivially calculate the current position of the planet from a circular motion

This isn't accurate, but once that works one can try more elaborate approaches, such as Newtonian 2-body motion for each planet. But that would be better done in a C++ module with a thorough plan in mind on how to handle orbits and coordinate systems.

rknepp

Much thanks! These are all great suggestions.

Yes, this is probably more complex and more precise than what should go into a game in most cases.

It started out as a training exercise to learn how to use Area2D gravity and slowly I added feature by feature. Some of things I tried probably don't make sense but I wanted to understand what they do anyway.

At some point it started to look like a Zach-like game where the player is presented with a starting state for a level, is given a few planet options and can drop them into the worldspace to see how they blow the whole thing up... with specific goals in mind (like plunging all planets into the stars in as few cycles as possible, or causing a large planet to be kicked out into interstellar space).

I already had the nbody orbits working (was easy with a bunch of Area2D's with gravity points) so I figured adding some initial velocity would be trivial (even knowing it would likely bring the nbody system crashing down at some point in future).

I really like the idea of simplifying the whole thing with Spheres of influence (or similar ways) to approximate paths. I will be trying some of these other suggestions as well.

Thanks again

Pixophir

Umh ... I assume the bodies with the red trails have some sort of propulsion, otherwise it looks strange. Reminds me of Ptolemy :-) But a Keplerian orbit is either a closed ellipse, or a parabola or a hyperbola wrt the central body.

Or it is a fantasy setting with an interesting story :-)

cybereality

DaveTheCoder But ... but ... our phones have more computing power than the computers used for Apollo 11.

Yes, but I doubt that Apollo 11 was running at 60 fps 👅

Pixophir

Hehe :-) I guess it was faster for the crew who had to search a spot to touch down while the err computer counted down the fuel than it was for mission control who went blue from holding their breath :-)

https://en.wikipedia.org/wiki/Apollo_11#Landing