Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

Planets gravity and orbiting

Discussion in 'General' started by jhnwgacy, Aug 29, 2015.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. jhnwgacy Trainee Engineer

    Messages:
    81
    Guess, it's possible.
    it's a pity, we can't draw navball on lcd panel.
     
    Last edited: Aug 31, 2015
  2. McTraveller Apprentice Engineer

    Messages:
    118
    Just a note to simplify things and remove guessing: If you think gravity follows a power law with respect to radius, you can find out the characteristic of the gravity by doing a plot of the acceleration versus the log of the radius. The slope of that line should match up with the "falloff" factor in the config because log (kR^x) = x log R + log k. You can even find out the GM factor from this, because GM = k.

    Good luck getting really close though; the physics engine is notorious for step-size issues (speed limit, landing gear, rotors, pistons, etc.).
     
  3. Dwarf-Lord Pangolin Senior Engineer

    Messages:
    2,597
    So the TL;DR I'm getting is that orbits are tricky but possible. They sound handy for satellites.
     
  4. buggsy Trainee Engineer

    Messages:
    86
    Yes, when acceleration is inversely proportional to radius the orbit looks like a spirograph.

    [​IMG]


    When acceleration is inversely proportional to the radius squared it looks like a real orbit. I ran into the same thing when my little gravity program didn't square the radius, and I was scratching my head for hours wondering what went wrong.

    [​IMG]
     
  5. jhnwgacy Trainee Engineer

    Messages:
    81
    So, it's simple at first look: Gravity falloff is a radius extent.
    Formula is probably somewhat like g=PlanetGM / R^Falloff
    But, there is a little factor, which makes things a bit more complicated and this formula gives some error.
    When we drop probe to surface of a planet, we can always explain error with lack of precision when calculating planet center or measuring acceleration of free fall, but precession of orbit indicates, that it's not that simple.
     
  6. Knsgf Junior Engineer

    Messages:
    538
    This is the actual formula that SE source uses:
    g = GM / (R - Rh + Ra)^Falloff,
    where
    * Rh is the value of <MaximumHillRadius> tag in SANDBOX_0_0_0_.SBS file,
    * Ra is <Radius> tag value from the same file.

    Because Rh > Ra, the gravitational acceleration will be tiny bit higher than Newton's law predicts, leading to observed precession of the orbit.
     
    • Like Like x 1
  7. JoeTheDestroyer Junior Engineer

    Messages:
    573
    That's one place. The other is line 482:
    Code:
    return direction * MyGravityProviderSystem.G * (gravityMultiplier >= 0.05f ? gravityMultiplier : 0.0f);
    
    Which cuts of gravity if the acceleration falls below 0.05*g_earth. For the default 7th power falloff, this one always takes precedence. I don't know about when you change the falloff, though.

    If you look at the code that calculates acceleration due to gravity (see link above), you can see that "radius" (distanceToCenter) used by the code is not actually the distance to planet center, but rather has a constant offset dependent on two planet parameters.

    Edit: @Knsgf beat me to it
     
  8. Multiscooped Trainee Engineer

    Messages:
    53
    Wow good job figuring all that stuff out. I hate numbers.

    I wonder if it would be possible to have an orbital space station that goes all around the planet's circumference, like artificial rings? Would it be too heavy and just crash eventually?
    Something like this:
    Eaw_Kuat.jpg
     
  9. Malware Master Engineer

    Messages:
    9,866
    Like I always say in threads like this: Don't trust what is in the current source code. It's a month old. I'd be willing to bet the rules for gravity will have changed by the time planets are released.

    Just so you can keep that in mind when doing these (very cool) speculations :)
     
  10. jhnwgacy Trainee Engineer

    Messages:
    81
    So that was the var affecting radius!=)
     
  11. McTraveller Apprentice Engineer

    Messages:
    118
    What? WHY!?!?!
     
  12. fourthquantum Senior Engineer

    Messages:
    1,286

    I'm guessing game play to make them more fun.
     
  13. McTraveller Apprentice Engineer

    Messages:
    118
    I'm not sure I understand why a constant offset to effective radius would have any impact on "fun". It just makes the code more complex.

    From what I can tell by looking at the code, the idea is to make a zone of constant gravity between the planet minimum surface and planet "maximum hill radius", but then have a falloff that makes gravity go away faster than in reality. The gravity falloff inside a planet (e.g., inside a hole that is dug out) is also non-physical; for a true spherical mass distribution, the gravitational field actually becomes linear with radius. The code is proportional to R/(R+planetRadius) which is quite nonlinear and higher than "reality" for all depths.

    I'm not saying what the code is doing is wrong - it is just far more complex than it could be. After all, in the example planet with a min radius of 24 km and a hill radius of 25km, "standard" gravity (R^2 falloff) only drops by 8%, which is pretty constant as it is - there's no real need to artificially make a "constant" gravity zone. I can't think of a need, gameplay-wise, to have a fixed gravity over a range of altitudes, or even have the gravity falloff more rapid than in reality.

    It would be nice if the source code had comments giving rationale why certain things are the way they are...

    EDIT: There's actually a bug in the code; when radius goes less than the surface radius of the planet, gravity is half what it should be, because the code is doing

    factor = 1 - A/(A+R)

    where A is the "average" surface radius of the planet. But if the actual radius is close to the average radius, the A/(A+R) term is going to be roughly 0.5, not 0. Whoops!
     
    Last edited: Sep 2, 2015
  14. fourthquantum Senior Engineer

    Messages:
    1,286
    I realise it should be linear inside a planet but the only reason (I can think of) why it does not follow real physics is because of game play dynamics. I can't understand why it wouldn't otherwise, I don't know the full thinking behind it.
     
  15. JoeTheDestroyer Junior Engineer

    Messages:
    573
    Due to the speed cap. Real orbiting isn't feasible (just look at the speeds the OP is moving in his tests, presumably using a speed mod). So the distance (and thus time) of concern is how far you need to get from the surface in order for the effect of gravity to become negligible.
    You can see in the code, the dev's think this point is when acceleration due to gravity drops below 5% of g_earth (it is cutoff to zero at that point). So we will use this.

    A 120km planet has surface gravity of 1.2*g_earth. To reach the cutoff we need gravity to reach 1/24th of the surface. With the current code values, this means the distance from center must be 60km*(24^(1/7)) which comes out to roughly 34.5km from the surface (or 5.5min of travel time at speed). If they were to use the normal inverse square, this becomes 234km from the surface (or 37min). Needing to travel almost 2/3rds of an hour just to leave a planet is not conducive to gameplay, whereas 5 minutes is just long enough (IMHO) to not trivialize the process while just short enough to not be annoying.

    Also, depending on how close planets end up being to each other, this could have a computational impact, with multiple planets/moons all applying gravity at once.

    Your argument is backwards. It's the need for a rapid falloff that drives the need for that fixed gravity hack on the surface.

    We know, this has been commented on in just about every gravity thread that has popped up.
     
  16. McTraveller Apprentice Engineer

    Messages:
    118
    I hadn't thought of that one - that does explain the need for rapid falloff*, but doesn't really explain the need for the constant acceleration zone. I'm not sure there's any gameplay effect of having an R^-7 falloff without complex code. I mean, is anyone really going to notice the difference on a 25km radius planet if the gravity drops 24% when you gain 1km altitude? (That is, what do you gain by having a zone of constant gravity magnitude? Apparently I can't think enough out of the box on that one to think of a reason.)

    When you've got code that's going to be computed on many objects at each physics iteration, you want to have it as simple as possible.

    *Like many others, I'd rather see a fix for the speed cap, rather than the continuous complexity that is being added to deal with it. But I do understand the difficulties inherent with that request.
     
  17. jhnwgacy Trainee Engineer

    Messages:
    81
    Yes, i've used speed mod for testing. 104 m/s is not enough for orbiting around 50 km planet.

    By the way, this method for calculation of g, used by developer, which makes orbit Apo to shift a bit with every turn is not too unrealistic.
    Precession of orbit is an observed fact for planets in Solar system:
    https://en.wikipedia.org/wiki/Apsidal_precession

    Maybe, a bit later i'll get back to this theme and try to make a table of speeds needed for orbiting using various settings for planets R, Rh and Falloff.
    Since we know how g is calculated: g = GM / (R - Rh + Ra)^Falloff, first space speed (speed needed to maintain circle orbit at specific height above planet) can be calculated easily.
    The more tricky is calculation of upper speed limit to keep your Apo inside gravity range.
    I'm not sure if it's available to maintain stable orbit without any corrections for falloff like 7.

    For realistic falloff=2 orbiting works fine.
    Within 104 m/s we wont be able to orbit planets, but for moons it will work.
    104 m/s is a proper orbital speed for g = 1 m/s (0.1g) and R = 10800 m.
     
  18. JoeTheDestroyer Junior Engineer

    Messages:
    573
    I believe they wanted surface gravity to be constant, from the lowest valley to highest mountain. That way it wouldn't change significantly while you're walking/driving around. It's just much cheaper to make the entire zone constant rather than trying to calculate surface position.
     
    • Like Like x 1
  19. McTraveller Apprentice Engineer

    Messages:
    118
    I'd be interesting in seeing the comparison of the CPU ticks with the "constant" gravity range versus just computing the falloff-based one with no branching. Branch prediction misses are *expensive*. But so are floating point divisions and the pow() function.

    Computational complexity aside, I would actually think it would be more fun to have gravity change from the top of a mountain to the valleys, but I can see the "make surface gravity constant" as a reasonable design choice.
     
  20. jhnwgacy Trainee Engineer

    Messages:
    81
    Tho, if i finally stop playing naturalist and look into source, i must agree, that formula for acceleration looks pretty strange:

    attenuation=(Ra/(R-Rh+Ra))^Falloff
    PlanetScale=Ra/50000
    g=9.81*Attenuation*PlanetScale

    So, it's:
    g=0.0001962 * Ra^(Falloff+1) / (R-Rh+Ra)^Falloff
    Awesome mix of weed with mushrooms :)
     
    Last edited: Sep 3, 2015
  21. Knsgf Junior Engineer

    Messages:
    538
    gpow.png
     
    • Like Like x 3
  22. JoeTheDestroyer Junior Engineer

    Messages:
    573
    @Knsgf Thanks for that, that's much clearer than the other explanations I found about why p>2 has no stable orbits.

    Expensive in C, yes. I'm still not convinced that C# is fast enough for it to matter...

    Still, compared to the cost of simply drawing the object in question on the screen, I doubt a few extra branches/adds in the gravity calculation are significant.
     
  23. jhnwgacy Trainee Engineer

    Messages:
    81
    Thnx for formulas.

    By the way here is some example I've done, playing with Keens formulas in matlab:
    Planet:
    Ra = 24660.3672;
    Rh = 25086.418;
    Falloff = 7;
    Cutoff=0.05;
    orbit R =33000;

    Here V start =151m/s;
    orbit1.png
    Here only 152 m/s:
    orbit2.png

    But we can maintain orbit with very low power consumption if we add script, orienting ship normal to Radius, and add very low thrust down to make total normal acceleration (gravity + thrust) equal to centripetal.
    Thrust= ((v^2/r) - g) * Ship mass.
    To stabilize 1000 tonn ship on this orbit we need approximately 10.5 kN

    ---
    But if we stay in speed limit (104m/s), we will need thrust of 350-370 N for every tonn of ship mass to keep the orbit. Pretty much.
    7 km higher (Orbit R=40km) we will use the same thrust for orbiting without any gravity.
     
    Last edited: Sep 4, 2015
    • Like Like x 1
  24. jhnwgacy Trainee Engineer

    Messages:
    81
    Finally, if we launch our satellite to polar orbit (khe-khe :p actually any orbit can be polar since our planets are immobile) and will not only maintain stable orbit using the script, but also add left thrust each time we flying above Northern Pole (lets call it so), we will get orbits like on this pic:

    Orbiter.png
    I guess, it can be used for mapping planet from orbit.
    Idea is folowing:
    Add a block of sensors to ships bottom, ajust em to different distances (probably i'll need modded sensors with increased range)
    And log their status to text panel.
    After all, transfer data from text to matlab and see if we can get a map of heights this way.

    Will see if we get image like this, got by Magellan satellite, which orbited Venus in years 1990-1994:
    600px-Venus2_mag_big.png
     
    Last edited: Sep 4, 2015
  25. mdenz3 Apprentice Engineer

    Messages:
    125
    Add an ore detector and map out where the ore is on a planet.
     
  26. Pennywise Apprentice Engineer

    Messages:
    338
    Tho, now detectors don't see planets.
    I'm noob with source code, so i don't know what to change in sensor to make it detect planet surface.
    Maybe, "MyVoxelMap" to "MyVoxelBase" or to "MyPlanet", but i don't really know.
    So, if one can make a sensor detecting planets, it'd be nice.
    Maybe, I'll need
     
  27. Spets Master Engineer

    Messages:
    3,214
    is the planetary gravity working the same as Natural Gravity mod by Digi? Because it looks like it doesn't matter how many thrusters you have with dampeners On, the ship will slow down, and almost stop completelly. Although still you will not have the Nforce necessary to take off, but it will slow down the falling. unless I messed up something.
     
  28. Pennywise Apprentice Engineer

    Messages:
    338
    Dampeners are more powerful than normal thrust, so they will probably decrease yor falling velocity to 0 even if you have not enough thrust to take off.
    In 1.091 compilation thrusters did not match gravity.
    Now i've 1.094 and there dampeners do compensate gravity precisely.
     
    Last edited: Sep 15, 2015
  29. chrisb Senior Engineer

    Messages:
    1,460
    I, because I'm not too 'up' on this type of thing, you know all the calculations needed to maintain a decent orbit. I will do as many other engineers have done in the past. A noble, thoughtful and tactful way around my shortcomings. I'll simply take apart a very good design built by an engineer that has more knowledge in this department.. and copy it.... :munch: :D
     
  30. entspeak Senior Engineer

    Messages:
    1,744
    This is all very, very exciting!!
     
Thread Status:
This last post in this thread was made more than 31 days old.