How will orbital motion work in KSP2?

[Clockwork13]

In KSP1, it's easy because the Sun is at the center of the universe and everything goes around it. However, if you have different stars that are gravitationally unaffected by eachother, then how would the positions of those objects be decided? Especially if you were to manually edit their orbits?

[GoldForest]

They're probably going to be locked in place or orbit a non viewable object.

It's been confirmed patch conics are coming back iirc, so there's only those two options really. 

Edited October 21, 2019 by GoldForest

[KerikBalm]

Plus some sort of "bespoke" solution for binary systems.

No details were given.

[GoldForest]

50 minutes ago, KerikBalm said:

Plus some sort of "bespoke" solution for binary systems.

No details were given.

More than likely it will be a quasi satellite orbit. That will mean tidally locking the two together and days are literally a year long, but hey, if it works, and doesn't cause game breaking bugs, I think I'll be fine with that. It also means one of them gets a retrograde revolution.

[mcwaffles2003]

Since KSP 2 is starting in 64 bit, (I'm guessing there will be no 32-bit version) it should be able to hold addresses 2^64 long, divide that in 2 for negative addresses and you get a grid of possible locations 2^63 units from center. If KSP 2 is accurate to the centimeter that allows a grid 2^63 cm out which extends almost 10 ly

So technically they could pick a point in the center of a bunch of stars, all several light years apart, so long as none of the stars move relative to one another out of the grid. Wonder if they use double precision floating point numbers because then I think you could fit the universe  in with sub atomic precision.

Haven't worked directly with this stuff so if I'm wrong, someone let me know.

But I suspect each solar system will have its own grid of relative values based on SoI. Stars relative to one another, planets relative to stars, moons relative to planets. 

[KerikBalm]

23 hours ago, GoldForest said:

More than likely it will be a quasi satellite orbit. That will mean tidally locking the two together and days are literally a year long, but hey, if it works, and doesn't cause game breaking bugs, I think I'll be fine with that. It also means one of them gets a retrograde revolution.

I highly doubt that, they would orbit each other far too slow, and if you try to orbit one of the pair, this will cause major problems.

I think that is actually one of the worst proposed solutions, but so far all proposed solutions are problematic. They may do a quasi 3 body since the game apparently supports thrusting during time warp, they could apply a "thrust" to simulate the gravity of the other body... but its really just speculation, they haven't given any details

[mcwaffles2003]

3 hours ago, KerikBalm said:

I highly doubt that, they would orbit each other far too slow, and if you try to orbit one of the pair, this will cause major problems.

I think that is actually one of the worst proposed solutions, but so far all proposed solutions are problematic. They may do a quasi 3 body since the game apparently supports thrusting during time warp, they could apply a "thrust" to simulate the gravity of the other body... but its really just speculation, they haven't given any details

I understand keeping the base mechanics of the game similar (patched conics) but 3 body isnt all that difficult on a computer so I dont see why they couldnt have that run specially for binaries and have the CoM of the system be put on a patched conics orbit of the star

[Guest]

I also very much doubt stars will have orbits. The maximum timescale for a campaign is in the thousands of years, and stellar motion won't be all that important in that scale. It would be observable but not so much it'd make a gameplay difference so probably not worth it. 

3 minutes ago, mcwaffles2003 said:

I understand keeping the base mechanics of the game similar (patched conics) but 3 body isnt all that difficult on a computer so I dont see why they couldnt have that run specially for binaries and have the CoM of the system be put on a patched conics orbit of the star

I doubt it, that would mean a naked singularity which would behave in a way that's so obviously and egregiously wrong it just wouldn't work. It has to be some other solution. 

[mcwaffles2003]

1 minute ago, Brikoleur said:

I doubt it, that would mean a naked singularity which would behave in a way that's so obviously and egregiously wrong it just wouldn't work. It has to be some other solution. 

why would 3 body mean a naked singularity?

[Guest]

1 minute ago, mcwaffles2003 said:

why would 3 body mean a naked singularity?

Not the 3-body, but putting the CoM on rails. 

Problem with 3-body is the same as with n-body, it makes it impossible to time-skip, you have to time-warp, and if you warp in bigger steps you get errors that compound and will likely eventually eject you from the system. This would be the case even if both planet were on rails and only vessel orbits were computed as 3-body problems. 

And I think time-skip is a bit of a requirement because of the long interstellar travel times and potential for campaigns spanning millennia. It's a tough nut to crack and I'm quite keen to see how they've cracked it.

[mcwaffles2003]

8 hours ago, Brikoleur said:

Not the 3-body, but putting the CoM on rails. 

Not necessarily, the CoM of a system of bodies is stationary relative to the systems inertial frame of reference. I wasnt suggesting giving that CoM any attributes like a SoI so it wouldnt hold any noticeable effects, it would just make the rotating system stay on rails.

8 hours ago, Brikoleur said:

Problem with 3-body is the same as with n-body, it makes it impossible to time-skip, you have to time-warp

Is there time skipping in kerbal already? If so I am unaware of it.

 

8 hours ago, Brikoleur said:

if you warp in bigger steps you get errors that compound and will likely eventually eject you from the system. This would be the case even if both planet were on rails and only vessel orbits were computed as 3-body problems. 

I get that but theres some algorithms that can calculate 3 body pretty quickly with good accuracy I'm sure but I understand the effects of approaching its limits.

9 hours ago, Brikoleur said:

And I think time-skip is a bit of a requirement because of the long interstellar travel times and potential for campaigns spanning millennia. It's a tough nut to crack and I'm quite keen to see how they've cracked it.

I think they havent included times kipping but have increased the multiplier of the time warping ability

[DStaal]

1 hour ago, mcwaffles2003 said:

Is there time skipping in kerbal already? If so I am unaware of it.

Yes: It's how (non-physical) time warp works - you skip ahead a certain period, and calculate the new position.  For that matter, even at normal speed there's essentially a timeskip between frames, of the duration of each frame.

 

(I'm of the opinion that you could likely do a 3-body simulation on ships in the Rusk/Rask system, keeping the planets themselves on rails, and have it work well enough for the game - but that's an opinion and I may be wrong.)

[Drakenred65]

13 hours ago, Brikoleur said:

I also very much doubt stars will have orbits. The maximum timescale for a campaign is in the thousands of years, and stellar motion won't be all that important in that scale. It would be observable but not so much it'd make a gameplay difference so probably not worth it. 

I doubt it, that would mean a naked singularity which would behave in a way that's so obviously and egregiously wrong it just wouldn't work. It has to be some other solution. 

Actualy we have binary stars that have orbital periods of under an hour. And that’s not the crazyest thing in the real universe.

 

[Guest]

5 hours ago, [email protected] said:

Actualy we have binary stars that have orbital periods of under an hour. And that’s not the crazyest thing in the real universe.

I meant orbits around a galactic core. If there are binary systems (and I would love them!) then they would certainly have to orbit around each other.

[Drakenred65]

Ohh I was thinking you were referring to long period or  wide binary s  since those can be have an orbit of around 1 light year or around 63,000 au wide, and given that the theoretical planet 9 has a  10-20,000 year orbit anything further out would have an even larger and longer orbit.

[Thygrrr]

On 10/21/2019 at 11:07 AM, mcwaffles2003 said:

Since KSP 2 is starting in 64 bit, (I'm guessing there will be no 32-bit version) it should be able to hold addresses 2^64 long, divide that in 2 for negative addresses and you get a grid of possible locations 2^63 units from center. If KSP 2 is accurate to the centimeter that allows a grid 2^63 cm out which extends almost 10 ly

So technically they could pick a point in the center of a bunch of stars, all several light years apart, so long as none of the stars move relative to one another out of the grid. Wonder if they use double precision floating point numbers because then I think you could fit the universe  in with sub atomic precision.

Haven't worked directly with this stuff so if I'm wrong, someone let me know.

But I suspect each solar system will have its own grid of relative values based on SoI. Stars relative to one another, planets relative to stars, moons relative to planets. 

This is not how any of those work. Nothing is simulated in one giant world, and for physics you need sub-milimeter precision or you will have to marry the Kraken.

 

Floating point numbers ("floats") are 64 bits in memory and usually 80 bits in the FPU, you can do double precision ("doubles") at double that size if you need to, but most game physics systems work using single precision.

This has nothing to do with the address space for useable memory, which generally is what x64 or 64bit refers to. IEEE 754 single precision floating point numbers as used in modern computers were 32 bits for over 30 years now, and they are great and practical pop for most purposes!

As a rule of thumb, single precision floats are most precise from -1.0 to +1.0, but sufficient precision for game play purposes exists out to 10000.0 if you stretch things (physics bubbles in KSP1 are 10km across). Double goes to roundabout 10 decimal digits. However, you almost never need that high a precision close up, and at astronomical distances, you sure want much much more than 10Gm before stuff starts jittering wildly. 

The same goes for computer 3D graphics, which get very wobbly if you want objects of 1m or less to smoothly move and be displayed next to others that are 1000s of kilometers big.

 

Sure, floating points numbers can express astronomically large numbers, but they are farther in between the higher they get, so a smooth 10m ball with a thousand vertices becomes a distorted mess when these vertices can only make jumps of 7m or more a couple AU away from the origin.

 

So games like KSP use dual coordinate scales, aka floating origin, usually one at the 1000 kilometer scale and one at the meter scale (mind you, at the 1000k scale you still have a lot of precision at the low end, but it can't work with physics or detailed visual objects). And when you get close, you need to switch on your closeup version of the object (usually terrain).

Then these two worlds are transformed and superimposed (KSP1 uses camera stacking, which actually is not easily available to KSP2 due to how the new Unity renderer works) to form one ILLUSION of a seamless world of astronomical size, yet full physical detail anywhere you go.

The meter scale is precise down to 0.1mm, which for physics is just about good enough, the 1000k scale goes down to 10 cm before calculations begin to jitter noticeably, which is great for orbits.

You can also work with double precision in game logic for the On Rails stuff, but in the graphics and physics stuff will need to be float, half, or even fixed precision (half and fixed usually just in shaders, including geometry shaders, where you only need a couple thousand subdivisions and GPUs treat floats a little differently anyway).

For the remote star systems, I am sure they will just add a third layer of coordinates, probably in the 1Gm or 1Pm scale (in the ballpark of solar systems or light years, respectively)

They could also make their virtual coordinate system be in double precision, but they would still need to create local floating origin bubbles to even illuminate and render the stuff in it, let alone move it in a physically convincing fashion.

 

Now one of the nicest things about the new 2019 Unity is that it allows multiple physics scenes to be simulated at the same time. This is great for multiplayer but also for crafts that split up and need to be individually simulated for atmospheric entry. In KSP1, these would just get unloaded and then killed by the rails system. I have high hopes for boosters with Parachutes actually making it back down to the ground in KSP2, instead of getting destroyed when they are more than 5km out.

Edited November 9, 2019 by Thygrrr

[mcwaffles2003]

@Thygrrr

thanks for explaining that all out, I had suspicions that this was how it worked

On 11/9/2019 at 3:29 AM, Thygrrr said:

So games like KSP use dual coordinate scales, aka floating origin, usually one at the 1000 kilometer scale and one at the meter scale (mind you, at the 1000k scale you still have a lot of precision at the low end, but it can't work with physics or detailed visual objects). And when you get close, you need to switch on your closeup version of the object (usually terrain).

 

On 11/9/2019 at 3:29 AM, Thygrrr said:

The meter scale is precise down to 0.1mm, which for physics is just about good enough, the 1000k scale goes down to 10 cm before calculations begin to jitter noticeably, which is great for orbits.

I'm surprised kerbal is accurate to the sub mm scale

 

Any idea if 2019 Unity will be capable of using a GPU to assist in any of this processing?

[Thygrrr]

Capable yes, but it requires specific coding.

GPU physics are generally for visual effects, not gameplay effects. But Unity 2019 supports them; especially with the DOTs stuff.

So exploding stuff can be accelerated. Gameplay... not so much (even though that is also possible; getting the data out of the GPU back into the memory where the game runs is usually the hard part, hard being "it's slow").

Edited November 10, 2019 by Thygrrr

[magnemoe]

On 10/22/2019 at 12:38 PM, Brikoleur said:

I also very much doubt stars will have orbits. The maximum timescale for a campaign is in the thousands of years, and stellar motion won't be all that important in that scale. It would be observable but not so much it'd make a gameplay difference so probably not worth it. 

I doubt it, that would mean a naked singularity which would behave in a way that's so obviously and egregiously wrong it just wouldn't work. It has to be some other solution. 

Agree, stars will be static, yes in real life they move but not very fast compared to the distance between them. 
you could have them in orbit around an central black hole. but this would have to be very far away to not give surreal high speed for stars. 

Another issue is that i see it as likely they will add star systems as DLC, some why buy it might be hundreds of year into the game. It would also be popular as mods. 
having moving starts makes this much more complex. 

The issue with Rusk and Rask is that they need both their own sphere of influence and and an common one relatively to the sun. 
The common one would then get an singularity in the center who would not work well. 
My idea is to make this SOI special, have gravity start to drop off again at some point and reaching zero at the center between them. 
This should create an stable point between them and let you do an 8 orbit around both, this would not be an stable orbit however. 
 

[ModZero]

On 11/9/2019 at 9:29 AM, Thygrrr said:

Floating point numbers ("floats") are 64 bits in memory and usually 80 bits in the FPU, you can do double precision ("doubles") at double that size if you need to, but most game physics systems work using single precision.

It seems like "large scale" space sims will become the exception - Star Citizen, for example, is built on doubles, AFAIK. But I think even they only do the physics in double precision, not rendering. And in rendering you need local space — far away objects are just dots and you don't actually do textures on them, and rendering a Kerbal walking on a surface of a planet can be fun.

[Thygrrr]

Yeah, but have you seen just HOW TERRIBLY things and objects in Star Citizen move? They are having the hardest time to make stuff interpolate, interact, and simulate even remotely realistically; stuff bounces around, falls through platforms, sinks into each other ALL THE TIME.

And I think the double precision bit really is just for their per-system general placement of physics bubbles, which then are probably going to be much simpler beasts than KSPs at long range, and at short range classical 3D-shooter-esque collision simulations. I mean, the thing is basically build on CryEngine==Lumberyard.

Edited November 11, 2019 by Thygrrr

[MechBFP]

Different solar systems will probably just be static like people said. Far enough away from the center to be moving in a straight line when approximated, and far enough away to be moving at the same speed when approximated. 

These star systems are probably going to be relatively very very close to each other (when compared to distance solar systems in real life) so it doesn’t take forever to get there with time warp. 

[SlinkyMcman]

On 10/22/2019 at 6:45 AM, Brikoleur said:

Not the 3-body, but putting the CoM on rails. 

Problem with 3-body is the same as with n-body, it makes it impossible to time-skip, you have to time-warp, and if you warp in bigger steps you get errors that compound and will likely eventually eject you from the system. This would be the case even if both planet were on rails and only vessel orbits were computed as 3-body problems. 

And I think time-skip is a bit of a requirement because of the long interstellar travel times and potential for campaigns spanning millennia. It's a tough nut to crack and I'm quite keen to see how they've cracked it.

So like my biggest problem with how physics in Kerbal is explained is that Kerbal doesn’t have 2 body physics. It has 1.5 body physics because one of the bodies isn’t a body because is has no mass because planetary bodies aren’t affected by gravity, they are on rails. All the sim does is asking what time it is. It makes 2trig calls to rectify the conic, that’s not 2 body physics. I’m not sure what the difference between rast/rusk and an ellipse is(please correct me if wrong). Rectifying the location in this situation shouldn’t be harder than x^2 (4) if you have a math major on the team(I’m not one so please correct me if you are), and the calculations can be made in parallel.

Key frames can be used for un-focused acceleration, so long as you know when the burn ends.

I anticipate sand boxing interstellar locations.

Edited November 13, 2019 by SlinkyMcman
Sober

[Daniel Prates]

I for one see no point in modelling body orbits so realisticly. Every scrap of processing counts and we may end up with a slower game. Complex calculations are much better used with crafts than planets, satellites etc. Insofar ksp1 has no orbir dacay due to microdrag, for instance, which is a thing I would be much more happy to see in ksp2 than the relativelly small benefits of having planets off their "rails" and into a calculated orbit.

[magnemoe]

3 minutes ago, Daniel Prates said:

I for one see no point in modelling body orbits so realisticly. Every scrap of processing counts and we may end up with a slower game. Complex calculations are much better used with crafts than planets, satellites etc. Insofar ksp1 has no orbir dacay due to microdrag, for instance, which is a thing I would be much more happy to see in ksp2 than the relativelly small benefits of having planets off their "rails" and into a calculated orbit.

Planets differ so little from an fixed trajectory its hardly matter. Merkury moves its Pe 1.5 degree/100 year.   
Only exception is that Duna don't wobble outside SOI because of Ike, To an lesser degree Kerbin too.
But as SOI uses the planet as reference frame it would not matter indside it would just make an close intercept for aerobraking harder.
This effect is also pretty easy to cheat.