Summery of gravity discussions that where lost

Talk among developers, and propose and discuss general development planning/tackling/etc... feature in this forum.
log0

Re: Summery of gravity discussions that where lost

Post by log0 »

@klauss and @maze try pioneer space sim. They're using a "set speed" (relative speed to target) controller and it works quite well. Now their spacecraft have got tons of thrust, so that there shouldn't be any issues with orbits. But the pilot can still choose whether he wants to do orbital maneuvers or not by switching to manual flight mode.

Some time ago I experimented with the same approach but with much lower thrust values and an additional selectable "set distance" (relative to target) controller which would allow some crazy maneuvers, like orbiting your target(using thrusters not gravity) while attacking it. I considered it a bit too hardcore for the space "first person shooter" sim gamer though.

PS: I am not suggesting to implement this in vegastrike, no idea whether it would work at all with vs sim and ai implementations.
IansterGuy
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Mon Aug 13, 2012 8:49 am

Re: Summery of gravity discussions that where lost

Post by IansterGuy »

pheonixstorm wrote:I wish the crash had not occured.. I had posted a bit of the Nano-Plague back story.. but anyway, Instead of features we really need to bugfix and refactor so that any advanced features such as walkable interior, 3d bases, planetary flight, gravity... will be much easier to add in w/o breaking things.
In the meantime adding story and missions probably wont interfere with any work being done on the game engine. Any mission or story should be made to still work even if new features are added. Maybe one could brainstorm.
maze wrote:in the end of it the only significant effect of gravity when you're flying around would be to make you waste a bit of fuel when you're moving at constant or zero speed.
But, two remarks:
1) if we actually had to fly all the way to the planet's ground instead of docking hundreds of kilometers from the ground, and compensate for the acceleration of gravity during the way, that little bit of fuel would be quite a lot actually.
It would be relatively a lot of fuel to land ever time. So planets would be something special. Maybe they would carry better and more products and lower price. I would expect that busy planets would either have a geosynchronous orbit space elevator and or a orbital space station with a fancy surface to space lift system. The stations would represent planet trade so capital ships would not need to land to get to the bulk of trade, but they may need to launch a shuttle to get more and better deals on the planet surface. Landing sequence could normally be skipped so it would be just like it is now plus an extra key press and fuel cost. Though if thrusters are significantly damaged, if fuel low, if under attack or for any reason the ship may crash, navigation will inform you to prepare for a manual emergency atmospheric entry. Reaching the surface without further descending would indicate a successful entry and could then be skipped by pressing the dock key again to get to a trade centre.
klauss wrote:
maze wrote:2) Fuel consumption is not the end of all to this story: one thing I would expect to be able to do and to witness other ships do if VS was a "finished" game would be to put myself/themselves into orbit. Capships in particular have rather NOT go down to the ground.
Well... that's the whole point I'm trying to make!
How do we reconcile orbits and orbital maneuvering with linear navigation?
There would need to be more advanced navigation controls in place in the regular game even before gravity got implemented. I think first implementing thruster based orbits would be an excellent transition method. As for how they would be controlled with they keyboard is an interesting problem that I had started to try to solve with my proposed keyboard layout. My solution was to use itineraries to allow reviewing and saving of paths. One could follow a path on either the small or large navigation screen and make adjustments to any point at a time or the hole thing. If the end of the path was made a repeating orbit using the orbit target button, then editing the path would make the orbiting endpoint less circular and more elliptical. I have a loose plan for what grouped keys would be used for such things. [<] [>] [/] would be for browsing itinerary and arrow keys plus modifiers would be all that is needed to adjust basic orbits.

***Here is the basic bits of a rough plan of itinerary related controls. These basic controls don't use keyboard modifiers, more advanced functions would use mostly the same keys combined with modifier keys.***
[O] Toggle orbit mode (Put the ship into a thruster or real orbit based on approach velocity and speed)
[O-then-O] (Circular orbit, set approach velocity to zero at current altitude)
<<<<Navigation controls for autopilot route selection>>>
[<] Follow route forward (default in VDU otherwise in full screen map)
[>] Follow route back (default in VDU otherwise in full screen map)
[/] Toggle advanced route editing menu (Open full screen map and allow click and drag editing)
[[<]or[>]or[/]then[up, down, left, right]] edit route in 2d looking down the path at the selected location
[/]activated[+] Increase orbit altitude
[/]activated[-] Decrease orbit altitude
[/]activated[Enter] Accept as route to target
[/]activated[Esc] disregard as route to target
[A] Autopiolot to target
maze wrote: What you have to do is measure speed not as the speed in the Galilean referential attached to the local sun, but as speed relative to an hypothetical circular orbiter around the strongest local attractor... ... 2)... Define a key binding to toggle between orbital speed, speed relative to target, stellar speed or if needed interstellar.
speed (Galilean referential attached to the black hole at the galactic center).
I believe that reference points would be automatically and manually set at the 'Strongest local attractor' by the ship navigation system. Using the key [P] as in ' Point of reference for governors'
maze wrote:Now, your ship doesn't need to spend any significant amount of fuel to maintain zero speed, if and only if the pulls of secondary local attractors are negligible in front of the pull of the strongest local attractor...
Another slight question mark is the stability of the retroaction when there's multiple possible circular orbits. In the end I tend to think that is a non-issue unless the nose of your ship is pointed radially relative to the strongest local attractor. ...Oh, I nearly forgot speed in the non-Galilean referential moving and rotating with strongest local attractor for planetary take-off and landing.
I think the game engines gravity formulas would handle the calculations well enough that you just select a new path and the ship goes there.
maze wrote:Relative speed of Mars and Eatth can be anywhere from 6000 m/s approx. to 54000 m/s approx.
If those were implemented, given how SPEC technology works, nearly the whole trip time would be accelerating from zero speed in the referential of the departure planet to zero speed in the referential of the arrival planet. Going from the Red to the Blue Planet in a ship with 5G accel, you'd need maybe 10 seconds to cover the distance at full SPEC multiplier, and... anywhere from 2 minutes to 18 minutes of acceleration to catch up with the earth's speed relative to Mars!
Now, keep in mind that in the very end all this is the direct consequence of gravity effects. Star system are kept together by gravity. It would feel weird to implement gravity in the form of attraction of skips by planets, but forget about planetary speed and the local sun's attraction.
You see the problem clear as day, but the solution priorities should be in the general order, game play first, then believability, then realism. I think the best solution to this problem was presented by PheonixStorm on the lost forums who said somthing like “Just synchronize the ship to local speed during SPEC, and don't tell anyone” Hide the evidence and keep it a secret LOL. I had thought the same thing and was trying to come up with a plausible explanation. The best one I came up with was essentially that the SPEC drive can in addition to warping through space with the Alcubierre drive technique, also use an intense gravity drive to quickly reach orbital speeds. It would work by shrinking space in front of the ship (also known as creating a gravity well) while resisting shrinking itself by expanding the space behind the ship (using negative gravity). The effect would be like haveing a blackhole infront of the ship and a white hole behind so that the ship gets pulled forward faster than normal. Haha I know it is a stretch to have such strong accelerations but accelerations are the only way to solve other than time commpression, I think it would only work while SPEC is active and we would only tell people who ask for an explanation. Or it could be useable other times by the pilot but it would have a much longer startup time than spec does, would be easier to jam, and be more sensitive to gravity so that in effect it would only really be good for interplanetary accelerations and maybe for reaching orbital speeds upon approaching a planet. It would then be hardly useable while already in any orbit except maybe a high orbit (High orbit is <1 orbit a day or 35,786km for earth).
maze wrote:1)Don't reduce accelerations of ships. SPEC as it now stands is to be ditched. Instead, SPEC or whatever it's called is now SF technology which reduces the Gs
I think ditching SPEC is a bad start to coming up with a solution to interplanetary velocity differences in a game that is supposed to be a fast pace shooter.
maze wrote:Amphibian submarine ships are cool btw, someone should be making a mod.
Just biological growing ship in general are cool too.
maze wrote: 3) Ditch SPEC as it now stands and replace it by cryogeny...
4) Ship computer wakes up the pilot.
4) altered by the player...don't want to spend too much fuel accelerating from and decelerating to zero orbital speed.
5) don't want to cap travel speed after all... efficiency/low acceleration thrusters... Use these to "slowly" accelerate until close to the speed of light. Relativistic effects kick in, including space compression/time dilation...
No making time compression necessary for a game planning to feature a open storyline taking place between planets. Ad Log0 said pioneer is a game that does this, and it intends to have no storyline.
maze wrote:7) is also optional. Simply put, we don't want 6) to utterly destroy all story lines, so we reintroduce SPEC multipliers, but only for interstellar travel...
This would still slow down the game too much for a space shooter if no SPEC was allowed in between planets.
log0 wrote:Some time ago I experimented with the same approach but with much lower thrust values and an additional selectable "set distance" (relative to target) controller which would allow some crazy maneuvers, like orbiting your target(using thrusters not gravity) while attacking it. I considered it a bit too hardcore for the space "first person shooter" sim gamer though.

PS: I am not suggesting to implement this in vegastrike, no idea whether it would work at all with vs sim and ai implementations.
I would suggest implementing this as a transition step to adding orbits for gravity. Orbits would then function with thrusters when there is no of not enough gravity. The [O] Orbital governor toggle key I'm planning would need a function for non planet targets anyways.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Summery of gravity discussions that where lost

Post by klauss »

SPEC magic that synchronizes frames of reference seems the best option to me.

It still has some details to iron out. Ie: it's simple to do when in autopilot (ASAP)... but how would one control this "magical acceleration" in manual (SPEC engaged, shift+A)? Does it still happen automagically? Why?

Not to mention the slight detail of how to justify it... which will come up eventually.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
maze
Hunter
Hunter
Posts: 94
Joined: Tue Oct 30, 2012 10:39 pm

Re: Summery of gravity discussions that where lost

Post by maze »

Lanster, thanks for reading my exageratingly long post. Here's another one.
IansterGuy wrote:
maze wrote: What you have to do is measure speed not as the speed in the Galilean referential attached to the local sun, but as speed relative to an hypothetical circular orbiter around the strongest local attractor... ... 2)... Define a key binding to toggle between orbital speed, speed relative to target, stellar speed or if needed interstellar.
speed (Galilean referential attached to the black hole at the galactic center).
I believe that reference points would be automatically and manually set at the 'Strongest local attractor' by the ship navigation system. Using the key [P] as in ' Point of reference for governors'
Yes I think we agree on this and understand each other here, but for the record let it be known that by orbital speed I meant speed relative to the circular orbit you would have around the strongest local attractor, and I think I wrote above that it would be the default mode for computing speed. What I was simply trying to add on top of that is that, since we'd have different attractors and the flight computer shifting between those attractors automatically, then the pilot should be able to force speed computation relative to some other attractor than the one the computer chooses (from a general stand-point every time there is a choice made by an algorithm of the flight computer automatically, then I will be of the opinion that this should only be a default and the pilot should be able to bypass it; for instance, I don't like that the max rotation speeds defined in units.csv can't be bypassed, be it just for for short amounts of time). Basically, when going away from the default mode, you'd be able to either set your speed relative to some target, or relative to some virtual orbit relative to an attractor which is not the strongest one.
IansterGuy wrote:
maze wrote:Now, your ship doesn't need to spend any significant amount of fuel to maintain zero speed, if and only if the pulls of secondary local attractors are negligible in front of the pull of the strongest local attractor...
Another slight question mark is the stability of the retroaction when there's multiple possible circular orbits. In the end I tend to think that is a non-issue unless the nose of your ship is pointed radially relative to the strongest local attractor. ...Oh, I nearly forgot speed in the non-Galilean referential moving and rotating with strongest local attractor for planetary take-off and landing.
I think the game engines gravity formulas would handle the calculations well enough that you just select a new path and the ship goes there.
I'm not sure what you mean here by "selecting a new path," on my side I'm not too sure it would be wise to compute gravity by what can be a dozen attractors in some systems. First, it's a physical simulation with a 1/r^2 interaction, and I believe it's not that easy. And second, when you have more than 2 bodies, it's chaotic in the general case! Sometimes the chaos is eliminated by the fact that the star(s) is much more massive than the planets, but not always. Some star systems that you make up with realistic weights prove to be unstable in simulations. In double star systems, the fate of planet is non-chaotic if they orbit very near to one of the stars or very far aways from both stars (in front of star-to-star distance). When there's 3 stars, one star is ejected in a direction which can't be predicted. Add a second moon around the earth, system becomes strongly chaotic, one of the three partners is ejected. In real life, we can speculate that we humans don't witness the occurrence of chaotic star systems because they and us are very short-lived in front of astronomical times. Just as we keep on dying at rapid pace, they keep on ejecting bodies until they are turned into stable star systems. But.. are we 100% confident that all of Vega strike's star and planetary systems are stable enough that eons are guaranteed to pass before planets and their satellites start taking weird moves?

Here's what I would do, in an attempt to simplify computations and increase stability:
Neglect the pull from stations, asteroids and ships (of course).
1 - Compute strongest local attractor:
Define a cut-off length, increasing like the mass of stellar bodies, and beyond which gravity is considered negligible. After a little dimensional reasoning I think having this cut-off length proportional to mass is the way to go. Gravitic acceleration decreases like 1/r^2, and is proportional to your mass M; the gravitic acceleration you need to capture a body of a given speed in your orbit decreases like 1/r --> the max distance at which you are able to gravitically capture a body of a given speed goes like M/r. Would you agree with that reasoning?
I believe implementing such a cut-off length will simplify the computation of the strongest local attractor. In addtion to that, at least one other trick can be implemented to save us a floating point comparison, for example: if a body is known to be closer to be closer to planet A than planet B, forget all planetoids orbiting planet B in the calculation.
2 - Compute gravity's pull:
2.1. Where the strongest local attractor is the local star, compute only the pull from the local star.
2.2. Where the strongest local attractor is a planet, compute only the pull from the local star and this planet.
2.3. Where the strongest local attractor is a planetoid orbiting a planet, compute only the pull from the local star, the planet and this planetoid.
IansterGuy wrote: You see the problem clear as day, but the solution priorities should be in the general order, game play first, then believability, then realism.
I mostly agree in general, but then if you find SPEC to be fun to play and believable, please tell me what model is mounted on your ship. Because mine does not always escape collisions, and my ship keeps making little turns around itself (and approaching things from the back, but that I can more or less wrap my mind around given how the technology is defined). The worse is that clean sweep targets decide to go full SPEC about 3 seconds after being spawned; now if there was no SPEC, them running away as fast as they could would only be fair.

Add to that, there's not only believability/realism of the physical universe, there's also believability/realism of human/alien societies/politics. With SPEC, VS makes us be a part of deadly and grandiose warfare (this I really mean without irony) between nations and empires whose mighty capitals lie... maybe 2-3 minutes away from each other.
IansterGuy wrote:
maze wrote:1)Don't reduce accelerations of ships. SPEC as it now stands is to be ditched. Instead, SPEC or whatever it's called is now SF technology which reduces the Gs
I think ditching SPEC is a bad start to coming up with a solution to interplanetary velocity differences in a game that is supposed to be a fast pace shooter.
You can keep things just as fast-paced with time compression.

Not to be saying that time compression is perfect and SPEC is always bad. All in all I think if we tried it might, and at this stage I'd only say might be that we'd make time compression work better and more enjoyably. Difficulty is to decide exactly when to allow it, and which ships should be accelerated along with the player's ship, so that things remain balanced and fair. I'd certainly think that for practical reasons, not all ships from a system can be accelerated, so we have a supposedly out-of-game effect which somehow invades the game world, which is a major drawback. Still, for as much as it would be unrealistic, a careful and clever implementation could make it believable.

Multiplayer would be a problem in itself. And a difficult one, but maybe not impossible.

As for story lines, I believe that if steady-state speed of ships is around 1.000.0000 m/s when forward burn finishes, and accelerations kept to their current values, storylines wouldn't have to be thrown to the garbage bin.

You're very right that non-FTL interstellar trips, on the other hand, pretty much kills most possibilities of storylines.

And final word, let's say that maybe it could be impossible to wrap one's mind around the idea of an out-of-game time pace change which for practical reasons can not be acting on all ships of a system... Then let's just say maybe I'd rather have an in-game device creating a local in-game time-altering field around a ship or a group of ships than SPEC under its current implementation.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Summery of gravity discussions that where lost

Post by klauss »

maze wrote:You're very right that non-FTL interstellar trips, on the other hand, pretty much kills most possibilities of storylines.
It's a dead-end then. Because, unlike pioneer, we very much would like to have a (or several) storyline(s).
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
maze
Hunter
Hunter
Posts: 94
Joined: Tue Oct 30, 2012 10:39 pm

Re: Summery of gravity discussions that where lost

Post by maze »

When we play VS, we have a choice between 2 possible referentials for computing speeds. When gravity is implemented, a third one will have to be added.

1- Let's say the default speed referential is circular orbital speed (for me that would be the most sound solution).
OK, so speed reference is speed you have in a circular orbit.
But there's an infinity of circular orbits which go through your current position, one has to be chosen.

1.1. The chosen orbit is the one which points through the nose of your ship.
You turn your ship around, your speed changes!
You turn your ship by 180 degrees, your speed has become 2x the speed of the local circular orbit!
Personally I'm perfectly fine with this, and I wouldn't mind the slightest. What about the average VS player? Is it something you think he can easily understand/accept?

1.2. The chosen orbit is always defined not by your facing, but by your current velocity relative to the body you're orbiting.
Ouch! Now there's multiple possible velocity vectors within galilean referentials corresponding to 0 speed in this mode! Numerical errors kick in, and your ship keeps changing orbits all the time!

2 - Default mode is speed relative to galilean referential attached to the local sun
You close in on the earth with auto-pilot, and shoot down gas when popping out of SPEC.
You see earth going away at some 24.000 m/s approx.
Note that this mode has now become pretty useless for any and all purposes
Rather than removing it, for the sake of completeness I'd simply hide it behind a non-standard key stroke, or even not bind it at all by default.

3 - Default mode is speed relative to your current target
Maybe this is what needs to be done (assuming that gravity is implemented). People who want to play a space shooter, after all, shouldn't be required to know or understand a lot about planetary mechanics... Those people would anyway still more or less follow orbits whenever their target does.

Myself and other players would however prefer 1.1. to be the default mode... More elegant, and less wasted fuel.
Conclusion: best approach is 4. make the default configurable. Players should be able to change not only the key binding(s) for toggling between one mode and the other, but also which mode is the default.
klauss wrote:SPEC magic that synchronizes frames of reference seems the best option to me.

It still has some details to iron out. Ie: it's simple to do when in autopilot (ASAP)... but how would one control this "magical acceleration" in manual (SPEC engaged, shift+A)? Does it still happen automagically? Why?

Not to mention the slight detail of how to justify it... which will come up eventually.
I'm not totally sure because I have yet to try it, but I think I'd prefer time compression to be the only alteration of the underlying physics --> compression factor X, speed increase by factor X, acceleration increased by factor X^2.

Either time compression is justified as an out-of-game effect. After all, it's just as if the movie was played faster. This should normally affect all of a system's ships. Probably not possible, alas, so let it just affect the player's ship and some other, well-chosen ships. It should also be impossible to trigger it in the vicinity of hostile targets.

Or, time compression justified by the existence of an in-game device (or two, or three, actually). I could see something along those lines. "The time compressor has been a restricted device accessible only to the higher end military capships, and to a handful of special forces craft for decades, before recent advances in mini black-hole technology democratized its use within Confederate and neighboring space. In normal operations, this device speeds up the passage of time relative to the rest of the universe, within a certain radius around its position. Some of these devices additionally implement a scrambling mode, whose use is illegal in some star system, and which utterly negates the effect of other time compressors within an even larger radius. Within the space-faring community, rumor is of an experimental device based on a similar principle, powering a bean which effect is actually to slow down time along its path."
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Summery of gravity discussions that where lost

Post by klauss »

log0 wrote:@klauss and @maze try pioneer space sim. They're using a "set speed" (relative speed to target) controller and it works quite well. Now their spacecraft have got tons of thrust, so that there shouldn't be any issues with orbits. But the pilot can still choose whether he wants to do orbital maneuvers or not by switching to manual flight mode.
We too use that "set speed" system, except your target must be locked for it to be used as a reference. Otherwise, it's automatically set to the nearest significant unit (ie: base or planet).

I tried pioneer, and I must say, if something's well ironed out is navigation there. A bit too complicated at first, though. It's elite in every way, and I love elite, but it does become too complex for the casual player (and VS is aimed a bit towards those, not too much, but a bit).

We really must do something like Pioneer's time passing while jumping from one system to the other, otherwise distances are meaningless. Although I like Pioneer's (Elite's) way of making you feel the distances, with maximum jump lengths, time passing while jumping, and all that, it becomes really complex in a way VS shouldn't be.

So... I always envision an autopilot similar to Elite's for VS, where you can choose one of many modes, and where autopiloting becomes the standard way of navigating. Elite's ships have way too much thrust for dogfighting, dogfighting in Elite and Pioneer always felt wrong. So VS ships ought to have less thrust, as we discussed.

Big ships won't be able to land or take off, and that's OK. That's expected.

We have to develop HUD aids to let pilots know and avoid gravitational hazards too. I believe a simple trajectory predictor (which predicts your orbit and shows it to you) would help wonders here, warning you when you're on a collision course and letting you bail out way before the PONR. In fact, it should display the PONR.

For all this, we have to make gravitational attraction a 2-body thing: planet and ship. The calculations are way too complicated if we try to add more than one attracting body to it.

Then, there's the AI. AI has to know how to navigate on this world.

I think we can handle this with a few AI kinds - capital ship AI would stay clear of planets, fighter AI would care less as it can break free in most situations, and shuttle AI, optimized for low-orbit maneuvers so we can populate space stations with those.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: Summery of gravity discussions that where lost

Post by pheonixstorm »

We also need to populate all populated planets with transit stations for the larger ships. We could also set an atmo flag for all ships for those that can or cannot land on a planet (or moon, we should really add some moons).

I think VS and most player computers should be able to handle additional calculations for gravitational fields within a system. Perhaps set them in stages to allow for gravity on slower machines and full gravity effects on dual core or higher. Most of the math we should be able to parcel out on multi core systems. As it stands VS could run on what... an old P233?
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Summery of gravity discussions that where lost

Post by klauss »

pheonixstorm wrote:I think VS and most player computers should be able to handle additional calculations for gravitational fields within a system. Perhaps set them in stages to allow for gravity on slower machines and full gravity effects on dual core or higher. Most of the math we should be able to parcel out on multi core systems. As it stands VS could run on what... an old P233?
Which calculations do you refer to? Applying gravity to all units? Or AIs computing trajectories to their target? (they're quite different beasts)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: Summery of gravity discussions that where lost

Post by pheonixstorm »

Gravity
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
maze
Hunter
Hunter
Posts: 94
Joined: Tue Oct 30, 2012 10:39 pm

Re: Summery of gravity discussions that where lost

Post by maze »

klauss wrote:For all this, we have to make gravitational attraction a 2-body thing: planet and ship. The calculations are way too complicated if we try to add more than one attracting body to it.
While I'm convinced you can and you should simplify it a great deal, I don't think you can simplify it all the way to a 2-body thing all the time.

For example, imagine you're orbiting Mercury. Can it work if you ignore the attraction from the sun? Or, you're orbiting Enceladus; can it work if you ignore the attraction from Saturn?

In fact that's the reason why I came up with the following suggestion above:

2 - Compute gravity's pull:
2.1. Where the strongest local attractor is the local star, compute only the pull from the local star.
2.2. Where the strongest local attractor is a planet, compute only the pull from the local star and this planet.
2.3. Where the strongest local attractor is a planetoid orbiting a planet, compute only the pull from the local star, the planet and this planetoid.
Hicks
Bounty Hunter
Bounty Hunter
Posts: 153
Joined: Sat Oct 22, 2011 9:17 am

Re: Summery of gravity discussions that where lost

Post by Hicks »

it all comes down to how accurate you want the calculations to be. When you look at orbits for satellites around earth, you rarely include the sun in you calculations. You do need to look at the phere of influence for the bodies you are orbiting around, and maybe workout in you are within the a certain margin you use gravity from the 2 relevant bodies
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Summery of gravity discussions that where lost

Post by klauss »

maze wrote:For example, imagine you're orbiting Mercury. Can it work if you ignore the attraction from the sun? Or, you're orbiting Enceladus; can it work if you ignore the attraction from Saturn?

In fact that's the reason why I came up with the following suggestion above:

2 - Compute gravity's pull:
2.1. Where the strongest local attractor is the local star, compute only the pull from the local star.
2.2. Where the strongest local attractor is a planet, compute only the pull from the local star and this planet.
2.3. Where the strongest local attractor is a planetoid orbiting a planet, compute only the pull from the local star, the planet and this planetoid.
I see... good point...
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
maze
Hunter
Hunter
Posts: 94
Joined: Tue Oct 30, 2012 10:39 pm

Re: Summery of gravity discussions that where lost

Post by maze »

Hicks wrote:it all comes down to how accurate you want the calculations to be. When you look at orbits for satellites around earth, you rarely include the sun in you calculations. You do need to look at the phere of influence for the bodies you are orbiting around, and maybe workout in you are within the a certain margin you use gravity from the 2 relevant bodies
You do not include the sun in your calculation... and you also neglect the fact that the earth is rotating around the sun. I guess it could work to neglect the sun for close orbits, say for example if you are orbiting around the earth closer than the moon. For more distant orbits, there's going to be issues. In the general case, neglecting the pull from the parent star is probably workable as long as the ship's orbital period around the planet is very small in front of the planet's orbital period around the star. But, many planets around VS have very close orbits around what I suppose are dwarf stars. Imagine also you are orbiting one of those moons of Saturn or Jupiter which have ultra-fast orbits around the gas giant: neglecting the pull from the gas giant would lead to problems.

Ultimately, if you want ships to orbit planets, I guess you also want planets to orbit stars. So, for consistency of the implementation you have better include the gravity of the star on ships close to that planet, also. Hence my proposal to make every object subject to the gravity of the body which provides the strongest pull in the current ship's location, plus the gravity of the "orbital lineage" of that object. And then, neglect all other objects.

Another benefit: simply submit planets and moons to the same rules as ships. Content creators won't have to manually enter orbit definitions when creating star systems (in fact, it's a must because I understand some systems are randomly generated). The content designer or random generator simply defines mass, radius and initial position of planets and moons. Then, the program does the following upon initialization of a star system:
1) class all celestial bodies by growing order of mass
2) starting with the lighter body, find the storngest local attractor of that body, compute speed of a circular orbit, define initial speed for that body (maybe the speed should be the speed of a circular orbit +/- some small random component)
3) go the next body in the list, and repeat the same procedure, except that if the strongest local attractor is a lighter body, ignore it and search for the next strongest local attractor.
4) The heavier body in the star system does not move, it's not attracted by anybody

Note the action/reaction principle has been broken, but who cares. Even double star systems would work to some extent by using this system (small extra care necessary; I may come back to this).

________

Actually, I have an idea which is an improvement of my previous idea.
The loop should calculate gravity on planets first, then moons, ships last. Then, for all bodies:

Code: Select all

Gravity Acceleration = Gravity Acceleration created by the strongest local attractor + Gravity Acceleration imposed on the strongest local attractor by its attractor(s)
2 benefits: your system is bulletproof-guaranteed to be dynamically stable. You save floating point calculations and instead go fetch some values in RAM.
IansterGuy
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Mon Aug 13, 2012 8:49 am

Re: Summery of gravity discussions that where lost

Post by IansterGuy »

maze wrote:
Hicks wrote:it all comes down to how accurate you want the calculations to be. When you look at orbits for satellites around earth, you rarely include the sun in you calculations. ...
... if you are orbiting around the earth closer than the moon. For more distant orbits, there's going to be issues. In the general case, neglecting the pull from the parent star is probably workable as long as the ship's orbital period around the planet is very small in front of the planet's orbital period around the star. But, many planets around VS have very close orbits around what I suppose are dwarf stars. Imagine also you are orbiting one of those moons of Saturn or Jupiter which have ultra-fast orbits around the gas giant: neglecting the pull from the gas giant would lead to problems.
I am pretty sure that if a station is orbiting a moon without accounting for the second largest attractor, that the orbit will eventually be stretched to the far side. It would not be so much an issue for planets orbiting a sun because their orbits are so slow in comparison to their satellites. Fuel for correcting orbits is cheap in game, but like Hicks said it would lower the detail because this warping of the orbit would get worse the smaller the difference between the pull of gravity between two sources in orbit.

If travelling between two large sources of gravity when the switch happens it could be abrupt and not at all seamless. This would cause there to be no gravity equilibrium between binary stars. Ships trying the fly straight down the middle would be pulled to one side every time. Since the plan is to ignore small scale gravity of stations on ships it may not really be an issue unless more detail is wanted like simulating the gravity of binary stars or an asteroid belt which could seem to be but not necessarily in some sort of orbit.
maze wrote: 2) starting with the lighter body, find the strongest local attractor of that body, compute speed of a circular orbit, define initial speed for that body (maybe the speed should be the speed of a circular orbit +/- some small random component)
So how would the object find it's strongest local attractor?Looking at it's classification distance then process of elimination?
maze wrote: 4) The heavier body in the star system does not move, it's not attracted by anybody

Note the action/reaction principle has been broken, but who cares. Even double star systems would work to some extent by using this system (small extra care necessary; I may come back to this).
I'm guessing that The binary star would be treated as one star by every object farther away and two objects when closer which is where the inconsistencies would be noticeable. To each other though since they are so similar in size they would orbit the Barycentric center. So maybe a rule would help for two or more objects of similar size close enough to cause abrupt changes in a orbit between greatest attractors. They would probably be treated as the same object from a distance, and when within noticeable boundries would the nearer the ship would take a shared influence based on how close to one or the other. To each other though instead of just calculating an orbit based on Barycentric coordinates, maybe chaotic behavior could be latter achieved by solving the n-body problem for locally similar sized objects. Maybe this could implement local ship to ship gravity to take into account the action/reaction principle? I don't know but it seems to me then the margin could be adjusted so that it could simulate in as much detail as the processor can smoothly handle. Maybe even it could done dynamically so the simulation gets more accurate when more CPU time is available.
maze wrote:Actually, I have an idea which is an improvement of my previous idea.
The loop should calculate gravity on planets first, then moons, ships last. Then, for all bodies:

Code: Select all

Gravity Acceleration = Gravity Acceleration created by the strongest local attractor + Gravity Acceleration imposed on the strongest local attractor by its attractor(s)
Seems like it would be good. What would be "all bodies"? Local similar sized objects to each other? Random asteroids? The stars to eachother? the planets effect on the hole solar systems Barycenter?
maze
Hunter
Hunter
Posts: 94
Joined: Tue Oct 30, 2012 10:39 pm

Re: Summery of gravity discussions that where lost

Post by maze »

IansterGuy wrote: If travelling between two large sources of gravity when the switch happens it could be abrupt and not at all seamless.
Sometimes maybe, but I doubt it, because this is fly-by-wire and the ship's thrust is by far the strongest source of acceleration whenever you're crossing this type of surface where your strongest local attractor shifts from one body to another. At worse, this is a discontinuity of acceleration, which is not as bad as a discontinuity of speed (or position of course). And I believe it will be a rather small discontinuity, for the very reason I just gave. Think earth and moon, or earth and sun, you're much much much below 1G gravity for both when you cross that surface.
IansterGuy wrote:So how would the object find it's strongest local attractor?Looking at it's classification distance then process of elimination?
I guess the answer is yes to both counts. I also guess, wisest thing to do would be, when a ship enters a system, have the program compute the radius of influence of each attractor once and for all. This radius of influence is the zone of space where the object is a stronger attractor than its own parent attractor. At every frame, it saves the time of computing 1/r^2 and replaces it by the time to compute a comparison between two floats. Then you go for the full formula in 1/r^2 only after having determined the strongest local attractor for everyone.

Edit: additionally, the zones of influence of planets will be distinct from each other, unless the star system is badly designed (I'm saying planets here, not planets and moons). This means that if the program finds an object to be within the radius of influence of one planet, it can forget about all other planets, and focus only on the moons of that planet. This principle which was applied at planet level can then be applied again at moon level. Also, if a ship is well inside the radius of influence of a body and not SPECing, the program can probably tag it so that it's not necessary to make the full evaluation of strongest local attractor again on the next frame.
IansterGuy wrote:
maze wrote:Actually, I have an idea which is an improvement of my previous idea.
The loop should calculate gravity on planets first, then moons, ships last. Then, for all bodies:

Code: Select all

Gravity Acceleration = Gravity Acceleration created by the strongest local attractor + Gravity Acceleration imposed on the strongest local attractor by its attractor(s)
Seems like it would be good. What would be "all bodies"? Local similar sized objects to each other? Random asteroids? The stars to eachother? the planets effect on the hole solar systems Barycenter?
As for the examples you cite, I'd neglect the object's gravity every time this is either a small object, or any object trying to attract a heavier body than itself.

But, all objects would themselves be subject to the "quick&dirty gravity" of stars, planets and moons, with two exceptions:
1) the heavier object in the system
2) asteroids. Asteroids currently in VS are a special case anyway because they're intended to stick around. For better or worse, this is star-wars-esque asteroids, not asteroid belts like we have in the solar system. Actually I guess you couldn't totally neglect gravity on asteroids either, just that at some point you'll have to cheat.

For single star systems, under my proposed simplification, content designers would have no other worries than having to make radii and distances vaguely realistic. The end result will be quite close to realism on short time scales, and always stable on long time scales.

The case of a double star system can also be handled by my proposed system I guess, though it could maybe not look that good if not designed with extra care by the content designer. True, gravity would be badly underestimated for planets distant for both suns, but the system is always consistent, even when it wanders far away from real-world physics. In the end, "extra care" here probably means that the content designer has to make planets either very close to one sun, or very far away from both, the scale here being the distance between both suns.

I am of the opinion that if you want to simulate real-world gravity in star systems, even newtonian gravity actually, it's perfectly feasible, but it's an application in-and-on itself, not something that can be a feature among dozens of other features in a game. Besides, you'd have the problem that systems which look perfectly fine at the start reveal themselves to be unstable in the end. That's the reason I think there has to be a bias which has both effects of simplifying calculations and guaranteeing stability.
IansterGuy
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Mon Aug 13, 2012 8:49 am

Re: Summery of gravity discussions that where lost

Post by IansterGuy »

maze wrote:Think earth and moon, or earth and sun, you're much much much below 1G gravity for both when you cross that surface.
... additionally, the zones of influence of planets will be distinct from each other, unless the star system is badly designed.
The dynamic systems now sometimes creates binary planets with moons half the size and orbiting so close that their rings that intersect the other. One could make rings less likely on moons and distances farther, but there is a problem that we all didn't quite realize. Even at it's far distance the earths moon is is not really earths satellite because the sun has twice the pull on the moon as the earth does, so the earth would not be it's largest attractor. Rather it has been proposed that the moon forms a double planet with the earth the planet and it's 1/81 massed moon, like Pluto and it's 1/9th massed moon. A quick search suggests the moon could be as close as apx 9000km from us before ripping the moon apart. If moon orbits where allowed to be as close as possible for a binary planet then some inconsistencies could be noticeable. Flying in between a gigantic similar sized binary planet both contributing say if possible 10G at a point in between. It would possible in real life to fly in between because I think most of the gravity would cancel. Though if gravity of one was ignored there would be no way to escape passing out from the gravity alone before getting sucked into the planet. Not even SPEC could save the ship because gravity interferes with any kind of gravity drive. If planets were at some point taken off of defined paths, I think that binary planets and maybe binary suns at the same time would need to be treated as the same object to distant objects, then as it gets closer phase in the influence to them separately. Until then I think dynamically calculated fixed paths maybe be necessary to get orbit stability if any binary masses are around. There seems to be plenty because they sure are pretty and large moons they say promotes weather for the development of life, and displaces the planetary centre of gravity making them harder to collide with.
maze wrote:But, all objects would themselves be subject to the "quick&dirty gravity" of stars, planets and moons, with two exceptions:
1) the heavier object in the system
2) asteroids. Asteroids currently in VS are a special case anyway because they're intended to stick around. For better or worse, this is star-wars-esque asteroids, not asteroid belts like we have in the solar system. Actually I guess you couldn't totally neglect gravity on asteroids either, just that at some point you'll have to cheat.
This would work well as long at there are no binary planets or stars. Since orbit calculations would be needed for the autopilot, there may be no point skipping the implementation of an orbital path calculating program. I wonder if there is an open source one around to dissect. With objects deciding upon their own orbit paths in that order of that magnitude mentioned, much would already be done. Binary stars could later be added and if someone want's to, they could expand the system to have dynamic orbits as you described. This is to say that at first everything including stations should be on a fixed orbit until someone feels like adding a better system on top of it.
maze wrote:The case of a double star system can also be handled by my proposed system I guess, though it could maybe not look that good if not designed with extra care by the content designer.
If stable orbits where calculated in order of magnitude with binary systems (Stars\planets\moons) treated as the same except to each other and passing ships, that would be a method that would work for any system featureing stable orbits. Unstable orbits may end with a solar catastrophe and such a thing would be possible with dynamic orbits, but there there really is no need for planets, but maybe for stations under attack. Like you said the developer would need to give the planet sane attributes for planets of binary stars otherwise the program may not find an eligible orbit at that location and radius. Otherwise because some crazy orbits are possible the weather may be really bad on the planet and not a believable cognizable world. Really all solar systems should be believable and the dynamic solar system generator could use some of those techniques too.
maze wrote:I am of the opinion that if you want to simulate real-world gravity in star systems, even newtonian gravity actually, it's perfectly feasible, but it's an application in-and-on itself, not something that can be a feature among dozens of other features in a game.
I am just trying to show that the door could be left wide open for more detail even after going for the simple solution, and that most likely the systems built on simple but expandable systems would be the best approach anyways for scalability on various hardware.
maze wrote: Besides, you'd have the problem that systems which look perfectly fine at the start reveal themselves to be unstable in the end.
Yup, this is exactly what I thought would happen solar system wise. Solar system wise a binary star and all planets would probably decide upon a fixed orbit during dynamic generation of the solar system based on the best fit orbit of a rough simulation. If one was instead to have it done dynamically orbits would be loose for the first 360 position change and if the path resembles an orbit, the path would be adjusted so that the ends would be closed and orbit would be set. The planet would be slowly accelerated toward that path so that by the next orbit it is fixed. It would then stay fixed unless a force greater than the corrective orbit force can knock it off the path. Though this is kind of pointless unless one wanted to quickly simulate solar system cataclysms or some other type of unstable situation like a ship orbiting an asteroids among other asteroids though I do agree asteroids should be cheated on like they are, belt or no belt.

My only relevant point is that deciding upon a simple system would be at its core fast and easy. If someone was crazy enough to want make the gravity simulation almost real down to the microgravity, that option could still be open. Currently I'm trying to focus on the things that make both gravity feasible and the current Vega strike better. Though I really like thinking far forward like this so to get an idea of what current systems could potentially aim to be like so to work well together.
maze
Hunter
Hunter
Posts: 94
Joined: Tue Oct 30, 2012 10:39 pm

Re: Summery of gravity discussions that where lost

Post by maze »

Even at it's far distance the earths moon is is not really earths satellite because the sun has twice the pull on the moon as the earth does, so the earth would not be it's largest attractor.
Arg... you're right. A very good point indeed. This means strongest local attractor would not be a valid criteria as I was thinking.

I guess there's got to be a limit distance which is the largest orbit-to-orbit distance at which the earth will capture a very small mass object circularly orbiting the sun. Or something along those lines, if you see what I mean. Have to think this through.
IansterGuy
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Mon Aug 13, 2012 8:49 am

Re: Summery of gravity discussions that where lost

Post by IansterGuy »

Actually not only that but if SPEC was assumed to be simply effected by the existence of gravity, this would make no sense either. But I have a solution since the universe is always more complex then it seems anyways. SPEC and your greatest attractor would be effected by the the mass and distance of course and size by some equation yet to be produced. The size would matter to SPEC because the high curvature of a nearby gravity source would effect SPEC more than the farther stronger gravity of the sun. As a ship in SPEC or a planet moves through space by a near object the gravity direction changes. SPEC would not be able to compensate quickly for strong moving or fluctuating gravity sources which would be simply determined by high mass (high gravity strength), and close proximity (high space curvature). I plan on proposing some changes to SPEC that make use of this more realistic phenomena.

Edit: I did propose some changes to SPEC here at http://forums.vega-strike.org/viewtopic.php?f=4&t=18448
omegakent
Explorer
Explorer
Posts: 12
Joined: Mon Dec 05, 2011 3:06 am
Location: Trujillo, Per
Contact:

Re: Summery of gravity discussions that where lost

Post by omegakent »

Greetings.
Before everything, I should say I didn't check the game engine deeply. In fact, until now I didn't realize that -as I can understand from the discussion- non-stellar objetcts are orbiting their star. For the given problem of adding gravity, one idea comes to me.
In order to economize computational resources, many approximations must be done. These aproximations should include neglecting some effects, specially low-mass gravity effects.
I consideer a gravity field approach. For this approach, any higher-than-a-minimun-mass body defines a gravity field. The limit must exclude all cargo objects, all missiles, all vessels, and probably low-mass space stations and asteroids. These leaves us only with the main star or stars, planets, and moons.
In time t = 0 hours, for each system, around each gravity-field body, regions like onion layers are defined, starting with one layer from surface to 'n * c * 1 s' (3E+5 km), with n = 1 for first layer, and increasing layer size with increasing value of 'n ^ 2', say second layer going from '1 * c * 1 s' to '4 * c * 1 s', and so on.
For each body, for average radius between layers, gravity field is calculated and value is stored as a vector. So then a gravity vector-field is stored.
For each body, layers with gravity field lower than a minimum-gravity-field-magnitude are assigned a gravity field value of zero. Also, as in a given region there are many gravity-field values, the gravity-field vector is the highest one affecting the given layer.
Then, the necessary suggested approach is that a given object, say a spaceship in a given space position, is only affected by the gravity field of one massive object. Gravity force is calculated only with gravity field vector and spaceship mass, and this defines a new acceleration vector, to be added to the general spaceship acceleration vector.
The gravity-field vector map is remade each hour, or so, depending on massive-objects orbital speeds.
Excuse me on my bad English, I'm from South America, not English native, and I'm sleepy as it's 01h38min here.
Hope I could help.
"Violence is the last refuge of the incompetent." Salvor Hardin in Foundation, by Isaac Asimov. New York, 1943.
IansterGuy
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Mon Aug 13, 2012 8:49 am

Re: Summery of gravity discussions that where lost

Post by IansterGuy »

omegakent wrote:Greetings.In order to economize computational resources, many approximations must be done. These approximations should include neglecting some effects, specially low-mass gravity effects. [...] for each system, around each gravity-field body, regions like onion layers are defined [...] For each body, for average radius between layers, gravity field is calculated and value is stored as a vector. So then a gravity vector-field is stored. [...] say a spaceship in a given space position, is only affected by the gravity field of one massive object. Gravity force is calculated only with gravity field vector and spaceship mass [...] The gravity-field vector map is remade each hour, or so, depending on massive-objects orbital speeds.
I see so this would be to reduce the CPU usage and instead take some stored values to avoid redoing too often some of the complex calculations. Did you intend this on a multi-body systems. Rather the calculations would be done only when they need to be updated. The only sudden changes seem would be when ships move from layer to layer; but which layer would the ship be on when between a double planet? Would every overlapping sector be it's own layer to be calculated a stored? I think this is how what your saying would work. It seems that any way this gets looked at, the planets need to be on pre-set orbits as it now or pre-calculated orbits, not dynamic ones even in my example where any interstellar objects can be knocked out of it predefined orbit or path with enough force. It seems to me that gravity would just as well be implemented simply like the current attempted "ADDS GRAVITY" patch supposedly does. Really the real issues are likely the creation of game play and the controls to more easily handle the navigation challenges.
Post Reply