Jump to content

Orbital Mechanics


wesbruce

Recommended Posts

Clearly orbital mechanics is a challenge.

Making planets orbit the sun and rotate adds several vectors to the players, ships and everything that must be tracked and adjusted for. 

I can see two possible solutions, one easy one hard:

Daily Update: Once a day at a predictable time everything is moved together, with a planetary bounding box being used; the box would be 1 or 2 planetary diameters and it would be moved 1 or 2 degrees around the sun. Note if the sun is orbiting the planets, the easy option, this is really a change of angles of all of the worlds to each other while either maintaining their distance from the sun or adjusting it slightly to emulate elliptical orbits. Any ship in the way is moved 1.5 planetary diameters to the side, sun ward. If it is still in the way it is moved another half planetary diameter in the direction of the orbit. If it is within 20 km of another orbiting object it is moved 20 km away from the planet.  If it is not clear of objects now then you need a space traffic cop! 

From the players point of view the sun seems to teleport but only once per day. If timed to correspond with night on the major planetary safe zone/ city, where most would be, it would go unnoticed. It would be a normal thing so would break immersion much less than a minecraft modded multiplayer day night shift which is quite common and often unnoticed. This would only be a 2 degree orbit shift from the point of view of the player seeing it.  

 

Frames of reference: 

Another method would be to give every player and ship a frame of reference state with 5 to 8 frames of reference. You need this for boarding actions in ship to ship combat and docking anyway.
At some point the person needs to be 'In the ship' as opposed to being in space or in another ship.

 

Why not planets, atmospheres. The frame of reference call is a velocity, vector and orientation call.  (The last thing will already be defined by a ship or stations gravity unit so may be ignored. If you want fancy space stations and ships where you can EVA on a belly of without falling off, the orientation call can be useful)

The reference frames would be: star, planet orbital, planet equator or Planet by latitude, Ship, Inverted, station, space station centrifuge. All in the same frame of reference are given the same velocity and the same vector relative to the local down. 

 

The star would not have a velocity or vector. A non moving space station is in the stars reference. a station is in the planets orbital frame. 

 

Planet orbit is the velocity and tangential vector of the planet in orbit. It would effect all things in the planets gravity and stations within a few planetary diameters. 

 

In the case of planet equator or Planet by latitude it would be the velocity of planets local surface & atmosphere [even on vacuum worlds. ] The atmospheric stickiness. It would have a primary component in the direction of spin and tiny downward component and a hand off component from planetary orbit.

 

Planet high latitude would grade off as you approach the pole but would be the same value for all in a given latitude. Ships taking off in the direction of spin end up transitioning to the stars frame of reference faster. However this transition will only occur is at an altitude of 1.1 planetary diameters of the core. Like wise a ship entering transitions fast if going in the opposite direction to spin. To avoid ship planet collision we could add a bounce angle, a real thing in space. If you approach a planet at the wrong angle you bounce off the atmosphere at a shallow angle.

 

In the case of Ship the reference frame is defined by the gravity unit and directional unit. Any one in the ship is given the ships vector. This is already planned so you can run around in the ship.

 

In the case of inverted, which can be set on a station, this frame of reference is set by a inversion hatch or door element. Gravity is flipped but the vector is unchanged. If you jump from space to a ship/stations belly and these gravity inversion elements are closer to you than the gravity generator then you transition to inverted. Pass though the inversion hatch or door element it flips inverted to ship or station frame. A rotating tunnel or monkey bar may help the transition (purely cosmetic). 

 

In the case of space station centrifuge this is a frame of reference generated by a special centrifugal gravity unit. (This is a long term thing not something I would expect in the game in alpha or beta or the first year.) This draws less power than a normal gravity unit and defines an axis. Down is relative to that axis and away from it. Gravity is proportional to radius in metres/ 1000. If the station has a static 1 RPM roll around the axis then the vector of the frame of reference is 16 m/s with a tiny down component. The floor stops you from flying off like a stone from a sling (until someone blows a hole under you). I've included this for completeness and future proofing.

 

In short the frame of reference is a state with a velocity and vector that is pre-calculated for all in the same reference frame relative to that reference frames gravity direction and type. This is summed with the payers/ constructs active velocity and vector. All players, etc with the same frame of reference on a given server can skip the frame of reference calculations and treat it as zero relative to the ship/ planet. 

 

Collision with a moving planet causes you to bounce off the atmosphere. Only crewed ships can avoid this bounce. (if AFK you bounce. )

 

All movable objects may need the frame of reference component. Rocks and trees may need it (this may be a problem ). If it works for planetary rotation it should also work for planetary orbital mechanics.  

 

OK now is time for a dev to shoot me down with the reason why this wont work. Both look obvious so I may be missing something.  :lol:

 

 

 

 

Link to comment
Share on other sites

You definatly put a lot of thought into it. I personally would love even realistic gravity, and maybe in 10 years we can get that. But I can tell you for now that is a lot of added calculations to tax the servers.

Sure its not many per player, but for thousands of players and millions of obkects it's a lot. And the devs seem to be taking large steps to reduce that for now. But once Carbon nanotube or Quantum computers hit the market its all good.

Link to comment
Share on other sites

Agreed - no shoot downs IMO. But yet another topic that we need to bundle into the general space/time/physics discussions :)

 

Two immediate thoughts:

 

1) Lagrange points - this is why option 1 would suck - it's the obvious spot to put deep space stations. so beyond the fact it will look crap from a player PoV looking out the window if you have a single daily update - your option 2 makes perfect sense IF the DU tech is as our tech is now - gravity matters, fuel and burn matters, you have to plot courses. But if it's more "Sci-Fi" where you go where you want without too much hassle (and assuming it's Hard Sci-Fi and we need to remain below .5 LY speeds so we don't need to deal with special relativity issues) - then are we overthinking this at this point?

 

Distance in system is pretty well massive - in terms of distance - remember, Earth to Moon is about 0.00257 A.U, or 384,400 km. That's a LOT of space.

 

At that scale - if an object is 20 km away from another object, they are pretty well the same object - THIS is where orbit/orientation/gravity is vitally important, but you could probably handle it locally (in a server sense) and only on a needs basis without necessarily needing to maintain positioning information in real time for all objects in space, or objects on an object in space - basically, for two objects to need to work out stuff at the level you've described, it's likely to always be a deliberate thing - random collisions are pretty unlikely in reality - so the "code" will generally know well in advance when two objects will need to have those calculations worked out.

 

Thoughts?

 

(I'm just stream of consciousness typing out loud - it's not a flame at all - I think your post is really interesting and something really worth discussing at great depth. Because I like that stuff :) )

Link to comment
Share on other sites

https://en.wikipedia.org/wiki/Sphere_of_influence_(astrodynamics)

 

Fancy trick for relative reference frames -- position and velocity of a game object is tracked relative to the soi the object is in. A quick recalculation is done when an object transitions to a new SOI. L-Points are not modeled with SOI, but the stable ones (4, and 5) can be faked if needed.

 

Here are a couple questions to put out there: in orbiter and KSP thust and fuel is limited so the player needs to understand orbital mechanics to get to where they want to go. If thrust and fuel is in copious supply then it is less of a consideration.

 

The other issue is playtime -- if the difference in fuel and travel time between different positions is meaningful (10 min at opposition vs 3 hours and 1000 fuel vs 100,000) then traveling to another body is a significant event for players and strategic for wars. If the difference is not significant due to how the game is balanced then no need for the extra complexity.

 

Also calculating the position of a body isn't terribly expensive. I got a python script that can handle many planets and moons in realtime using the 6 keplurian parameters. Writing it in C and simplifying some of the mechanics the impact is almost trivial.

Link to comment
Share on other sites

Well if you take sci-fi engineer be a and a lot of fuel to a asp style like gravity, then most players will whine nonetheless because they just crash on the mün or other bodies.

 

You need to get away from planet - piece of cake assuming engine and fuel is sci-fi.

 

Then you have a escape velocity and fall towards the inner planet.

You have to get apoaps in orbit and burn retrograde there (or use in combination with aerobraking) - all new players and non ksp players will fail hard here.

 

Orbits would be very nice and jc said that there will be one. But please no too difficult model (like ksp though I wouldn't mind) and no too easy one which doesn't add anything

Link to comment
Share on other sites

I doubt servers calculate physics, they should just track position. It is expensive on your hardware to calculate, but usually only if there are many particles floating around you, or in large scale battles.  And ofc particles and battles have priority over realistic gravity.

Link to comment
Share on other sites

A space exploration game without physics is pretty much useless in my view but i don't think gravity could be implemented mostly because of the obvious computation limitations but also because of the physical limitations. You couldn't make a planet just 100km wide with the same gravity as earth and expect it to behave like earth. The closer you'd get the stranger things would get (also mining would be just stupidly dificult because of the high density).

 

I would say the probably easiest way to implement gravity is to make it a fixed value around to about tenth of the planets diameter distance from the surface (to keep it closer to real) and then for around 50km distance, make it a decreasing value with the square distance (the equation is fairly easy to implemente i think. It would be rather hard to build a gigantic space station since the parts closer to the planet would experience higher gravity than those further away and the whole construct would be ripped apart because of the tidal forces)

 

All in all gravity seems like a pretty grimm option depending on how they might implement it ( I still want it tho  :D )

Link to comment
Share on other sites

You definatly put a lot of thought into it. I personally would love even realistic gravity, and maybe in 10 years we can get that. But I can tell you for now that is a lot of added calculations to tax the servers.

Sure its not many per player, but for thousands of players and millions of obkects it's a lot. And the devs seem to be taking large steps to reduce that for now. But once Carbon nanotube or Quantum computers hit the market its all good.

Right but Quantum computers will be bad in this kind of calculation. I wondered about a quantum data transmittion module. You would have one on the server and one on the client for instant trasmission but i think quantum computers will be used more for intelligent AIs because their unexpectable behaviour.

Link to comment
Share on other sites

You don't have to realistically simulate gravity to create realistic orbital mechanics. Yes if you wanted ships and stations to exert gravity on each other it would be a huge problem.

 

You could have the planets and moons on a fixed orbital track and rotations and then have ships just be effected by the closest planet they are near to (or the nearest star between planets), other ships and other planets would have no effect. With just one source of gravity simulating and predicting the course of the ship would be easy for the servers.

 

If you have a construct that is not accelerating just in an orbit that is stable you would not have to physically simulate the ship or send updates to clients you can predict for any future time exactly where it will be.

Link to comment
Share on other sites

Also when you build a station you can only place the static core module if you are in a orbit that does not go below the atmosphere and once deployed you cant knock it out of orbit either by accelerating it or crashing into it. As much as it would be cool to see an 8km ship crash into a city I think it would be game breaking

Link to comment
Share on other sites

I doubt servers calculate physics, they should just track position. It is expensive on your hardware to calculate, but usually only if there are many particles floating around you, or in large scale battles.  And ofc particles and battles have priority over realistic gravity.

 

Servers HAVE to calculate physics, and physics are cheap if well done (using octtrees etc...). The problem is to share the data between players as it is quite cpu-time intensive. By deferring the physics on clients you would need to verify and crosscompare the results of ALL clients in an area and determine if someone is cheating, and then update in case there are precision errors etc... which is more expensive than actually calculating the physics on the server. It's just a matter of adding vectors and doing simple integration. Collision tho, is the real problem, and that can only be done server side if those can damage cubes, since the quantity of data to collect and analyze would be ludicrous.

 

Not talking about hackers or community modding to counteract this measure and exploit that democratic system.

 

Hope it helps you understand why it can only be done on servers if you wanna be able to let people with a small upload speed play correctly.

Link to comment
Share on other sites

To be able to simulate orbital physics correctly, you would not only need frames of reference but different voxel octtrees: one per structure. 

 

The system is simple:

the universe has a plane of reference containing solar system planes of references, those are static.

Solar systems store the combined center of mass of all bodies in the system, and create the orbit ellipsoids around it. the center of mass moves with the planets and thus simulate the N body system in some ways (the orbits have to be slightly changed every update but that is quite cheap as it is a change in position of the body, but not changing the energy.

 

same goes for planets and rings/moons/asteroids etc scaling down. when it comes to planets frames of references in atmospheres, those are relatively static, (unless there is a superstructure but that will not happen in the next 2 years) and thus can live directly in a child/parent reference relationship.

Link to comment
Share on other sites

Orbits are trajectory rings around planets and as for game mechanics it could be considered as so.

 

Not using any physic but considering invisble rotating parking lots, where ships could attach themselves to it and start an orbit around planets

there could be multiple slots on each ring, and multiple layers of rings

 

An automatic orbit could be just done by parking on any of the closest free slots

Once parked the ship property turns to non physical and be just transported by the parking lot faking an orbit without any physical calculation 

 

 

for more tech info about orbits:

 

https://youtu.be/RDPU0LqtkRI

Link to comment
Share on other sites

Agreed - no shoot downs IMO. But yet another topic that we need to bundle into the general space/time/physics discussions :)

 

Two immediate thoughts:

 

1) Lagrange points - this is why option 1 would suck - it's the obvious spot to put deep space stations. so beyond the fact it will look crap from a player PoV looking out the window if you have a single daily update - your option 2 makes perfect sense IF the DU tech is as our tech is now - gravity matters, fuel and burn matters, you have to plot courses. But if it's more "Sci-Fi" where you go where you want without too much hassle (and assuming it's Hard Sci-Fi and we need to remain below .5 LY speeds so we don't need to deal with special relativity issues) - then are we overthinking this at this point?

 

Distance in system is pretty well massive - in terms of distance - remember, Earth to Moon is about 0.00257 A.U, or 384,400 km. That's a LOT of space.

 

At that scale - if an object is 20 km away from another object, they are pretty well the same object - THIS is where orbit/orientation/gravity is vitally important, but you could probably handle it locally (in a server sense) and only on a needs basis without necessarily needing to maintain positioning information in real time for all objects in space, or objects on an object in space - basically, for two objects to need to work out stuff at the level you've described, it's likely to always be a deliberate thing - random collisions are pretty unlikely in reality - so the "code" will generally know well in advance when two objects will need to have those calculations worked out.

 

Thoughts?

 

(I'm just stream of consciousness typing out loud - it's not a flame at all - I think your post is really interesting and something really worth discussing at great depth. Because I like that stuff :) )

One way to reduce tax on servers and still have gravity is where only planets draw gravity, and the object has to be above a certain weight. It simply pushes you constantly towards the center of the planet, so the server doesn't have to calculate which end of your ship is heavier. If something has enough power (lets say 5 times the minimum thrust to fly the server makes it so it will not be affected by gravity.

Link to comment
Share on other sites

I doubt servers calculate physics, they should just track position.

 

But to be honest, gravity is a function of position. Like was mentioned earlier - and this really depends on exactly how the meshing of player "grids" is done, you don't HAVE to calculate gravity for every single object in the game, since objects in a similar reference frame have exactly the same gravity vector. All of them. Gravity changes as a function of the inverse square of the distance to the object - but planetary/lunar masses are so large that you're not going to see a real difference over a few hundred or even thousand km. Lack of gravity is not the reason astronauts in the ISS are "weightless", for example. The gravity 60 or 100km up is almost the same (within a few decimal points) as on the surface.

 

So you calculate once for the "region" and everyone with positions corresponding to that "region" has a g value of "x". Well x-arrow, cos it's a vector :)

 

Now if your "region" is slowly moving around on the map and its position is changing relative to large planetary masses, you do have to recalculate the gravity vector for the region every once in a while - but you don't have to do that every iteration through the game loop. You can easily get away with it once every few hours or so unless said region is moving at relativistic speeds.

Link to comment
Share on other sites

I'm not for orbital mechanics myself. It's just too taxing on math and of course players. I talk to a lot of people on my friends list who have kerbal space program and most them have never even gotten a proper orbit... They just enjoy building ships and watching them blow up.

 

The point is that such a complex feature is just too much.

 

Not only that but even if it were to be added they are so far into the future ignoring engine tech the computer would do all the work. Meaning leaving a planet might take an extra 30+ Minutes for the computer to do all the work trying to leave.

 

I think the idea is not to be as silly as No Man Sky and blink from the planet so fast but also not to be as slow as say Space Engineers and that was does not do orbital mechanics just gravity. 

 

Trust me I love the idea but I also see in a large scale of things outside of calculations for the servers and such just the sheer amount of players it would turn off would be devastating. 

Link to comment
Share on other sites

There's still a lot of unknowns to be able to say for sure. We should ask about orbital mechanics in the AMA currently running to get more info. Videos have shown little difficulty in flying up and out of a planet's atmosphere, but then again, the atmosphere and gravity may have been manipulated from the norm in order to make those videos.

 

In my personal opinion, I would not like to see anything difficult. Not everyone wants this to be utterly realistic. I think I read a suggestion somewhere that said SOI should be used. Gravity would extend out only to X distance, where it would cut off, or be designed to hit 0. But the planet's frame of reference SOI would extend further, say X+1000m. This way, anything between the range of X and X+1000 would be in "orbit."

 

I'm also worried about how collisions will be handled, too. In Space Engineers, the artificial speed limit was introduced to allow collisions to remain realistic. I'm curious how this will be handled in DU, since we'll also be able to use FTL, which presumably travels many times faster than sublight movement used in orbital mechanics.

Link to comment
Share on other sites

Ähm since I didn't bother to read everything to this point sry if this is already mentioned.

 

This is based on my assumptions and educated guesses.

 

As I understand each object in DU uses a local grid and depending on mass and distance objects get absorbed into the bigger/heavier grid.

This is an octree like structure and allows for fairly cheap calculations. So a rotating planet rotating around a sun should be no problem at all.

Link to comment
Share on other sites

Wow, never realized the complexities in game design.  I'm just thinking what type of computer system I'll need to run the game. Any advise?

At this point any educated guess would be a wrong guess. Being nothing more then a pre-alpha (tech demo) there would be so many performance issues and bleeds and things they are changing every day that there would be no point in educating a guess as next week it would change. 

Link to comment
Share on other sites

Ähm since I didn't bother to read everything to this point sry if this is already mentioned.

 

This is based on my assumptions and educated guesses.

 

As I understand each object in DU uses a local grid and depending on mass and distance objects get absorbed into the bigger/heavier grid.

This is an octree like structure and allows for fairly cheap calculations. So a rotating planet rotating around a sun should be no problem at all.

 

well its not about planets orbits around suns, since planets arent physic

 

its more about ships/satelites orbits around planets

Link to comment
Share on other sites

Using this model it doesn't matter in which scope you are applying forces. (Just don't try to mix the scopes without proper conversion)

An orbit is a very simple principle basically you are moving so fast that you are able to permanently miss the ground in your falling motion.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...