Surface fixed and rendezvous reference frames

[Chocolat Oreos]

Hello, things that I would really like to see in KSP 2 are surface fixed reference frames, let me elaborate:

There is this mod called principia, it models n-body gravitation and has an option to manually change reference frames, one of the options is a surface-fixed one. This one is really useful for analyzing how a satellite drifts in say a geostationary orbit, or even a Molniya orbit, and is really nice for fine tuning orbits like that. Here is an example how this would look in a RSS KSP 1 system in a geostationary orbit:

Here you see a satellites history as it moves into GEO (using RSS + principia). It is clearly visible that at the final trajectory, the satellite has very minimal movement with reference to the fixed surface of Earth (in map view). 

In principia there is also this other reference frame, where you can select a target, and the target becomes the center of the reference frame (like the visual effect you'd get when you get an encounter with another body), this is way more intuitive to look at than 2 closest approach markers as we would have in stock KSP 1.

 

I would really enjoy these features in KSP 2, if possible.

Edited May 22, 2021 by Chocolat Oreos
said stock while it was RSS

[Incarnation of Chaos]

Are reference frames even a thing in the conics approximation? You can't have a reference frame for a separate body when you are deciding a specific one is basically the center of your universe at a given point. 

Well, that's partially lies. You have one reference frame, which is the body that you're within the SOI of.

That all said, there had to be a way. Otherwise manuever nodes and interplanetary transfer wouldn't even work.

So I'm kinda stumped on the details.

[Chocolat Oreos]

13 hours ago, Incarnation of Chaos said:

Are reference frames even a thing in the conics approximation? You can't have a reference frame for a separate body when you are deciding a specific one is basically the center of your universe at a given point. 

Well, that's partially lies. You have one reference frame, which is the body that you're within the SOI of.

That all said, there had to be a way. Otherwise manuever nodes and interplanetary transfer wouldn't even work.

So I'm kinda stumped on the details.

I think stock handles switching reference frames already (automatically) with encounters in map view (i.e. clicking on a planet when there's an incoming encounter and seeing how it will fly by based on that planets inertial). So I presume handling a surface reference frame should also be possible, although maybe a bit trickier to implement with a stock like conic system on rails. 

[mcwaffles2003]

I like this idea, I find it cool when making a rendezvous that having one ship as a reference frame really helps predict when the best time to maneuver the other ship is.

[Chocolat Oreos]

1 hour ago, mcwaffles2003 said:

I like this idea, I find it cool when making a rendezvous that having one ship as a reference frame really helps predict when the best time to maneuver the other ship is.

I agree, and for anyone wondering: Here is an example to what a target reference frame can do:

Here you see a kerbals position with respect to a lander (stock + principia). And its a bit more visually understandable to see what's going on here. The only downside is that you can't see if your spacecraft will crash into a body on its way towards the target. This reference frame is partially the reason I completely switched to principia a while ago. 

edit: Note that here you can also easily see the ascending / descending node compared to the targets orbit, so it's nicer to adjust inclinations like this too.

Here is another example, like this you not only get to see the first closest approach, but one that is 2 days ahead. Here a simple prograde maneuver is planned to intercept an orbit from a satellite in a different orbital plane. 

After that it's really easy to adjust a closest approach with a second maneuver.

Edited May 23, 2021 by Chocolat Oreos
added another example

[Incarnation of Chaos]

5 hours ago, Chocolat Oreos said:

I think stock handles switching reference frames already (automatically) with encounters in map view (i.e. clicking on a planet when there's an incoming encounter and seeing how it will fly by based on that planets inertial). So I presume handling a surface reference frame should also be possible, although maybe a bit trickier to implement with a stock like conic system on rails. 

Yeah I think you're spot on, so KSP2 would just have to move some of the functions out of specific actions and into a more general panel of options.

[cubinator]

On 5/22/2021 at 4:01 PM, Incarnation of Chaos said:

Are reference frames even a thing in the conics approximation? You can't have a reference frame for a separate body when you are deciding a specific one is basically the center of your universe at a given point.

I think I've seen surface fixed frames as an option in the Trajectories mod that calculates atmospheric entry.

[mcwaffles2003]

On 5/22/2021 at 5:01 PM, Incarnation of Chaos said:

Are reference frames even a thing in the conics approximation? You can't have a reference frame for a separate body when you are deciding a specific one is basically the center of your universe at a given point.

Thinking about this mathematically isn't this just a change of basis? if A is in reference to O and B is in reference to O then there should be a way to have A referenced to B. It's been a while since I learned linear algebra and haven't applied it to programming but my intuition leads me to believe this shouldn't be a problem.

[Incarnation of Chaos]

On 5/24/2021 at 5:33 AM, mcwaffles2003 said:

Thinking about this mathematically isn't this just a change of basis? if A is in reference to O and B is in reference to O then there should be a way to have A referenced to B. It's been a while since I learned linear algebra and haven't applied it to programming but my intuition leads me to believe this shouldn't be a problem.

Yeah the more I've thought of it the more i've realized KSP stock already does this on a limited extent.

I think I'm just not as familiar with Reference Frames in general as i should be.

[HenryBlatbugIII]

On 5/24/2021 at 11:33 AM, mcwaffles2003 said:

Thinking about this mathematically isn't this just a change of basis? if A is in reference to O and B is in reference to O then there should be a way to have A referenced to B. It's been a while since I learned linear algebra and haven't applied it to programming but my intuition leads me to believe this shouldn't be a problem.

You're right if we're just talking about instantaneous locations and velocities, but it's more complicated when we're talking about continuous orbits.  In the normal SOI reference frame, an orbit is always an ellipse (or other conic section).  However, in a surface-fixed or rendezvous target reference frame, it's unlikely that your current orbit is even a closed shape (unless your current orbital period is an integer multiple (or divisor) of the planet's rotational period or your target's orbital period).

Note that the "rendezvous frame" orbit that Chocolat Oreos posted above isn't a simple ellipse; it's an elliptical spiral that almost, but not quite, repeats (and is only drawn for ~4 orbits).  If you aren't already close to a stationary orbit or a rendezvous, your orbit could look like a many-petaled flower in these frames.   The orbits are still calculable, but it's complex enough that I would be surprised if the devs decide that this functionality is worth including in the stock game.

(Don't get me wrong; I think this is a great idea.  I just think it's more likely to be done as a mod.)

[mcwaffles2003]

22 hours ago, HenryBlatbugIII said:

You're right if we're just talking about instantaneous locations and velocities, but it's more complicated when we're talking about continuous orbits.  In the normal SOI reference frame, an orbit is always an ellipse (or other conic section).  However, in a surface-fixed or rendezvous target reference frame, it's unlikely that your current orbit is even a closed shape (unless your current orbital period is an integer multiple (or divisor) of the planet's rotational period or your target's orbital period).

Note that the "rendezvous frame" orbit that Chocolat Oreos posted above isn't a simple ellipse; it's an elliptical spiral that almost, but not quite, repeats (and is only drawn for ~4 orbits).  If you aren't already close to a stationary orbit or a rendezvous, your orbit could look like a many-petaled flower in these frames.   The orbits are still calculable, but it's complex enough that I would be surprised if the devs decide that this functionality is worth including in the stock game.

(Don't get me wrong; I think this is a great idea.  I just think it's more likely to be done as a mod.)

Why does the finished product have to be a closed shape or ellipse? Just have maximum draw time limits. You already have the 2 ellipses you're multiplying, you're just transforming one with respect to the other. Also, Chocolat Oreos image comes from an N-body system, not patched conics so it's obviously going to show more complex patterns. I still doubt the computation will be very intense though as it's just matrix multiplication of equal time points with a line connecting each point.

 

That all said, I doubt this feature will show up also. 

[Chocolat Oreos]

2 minutes ago, mcwaffles2003 said:

Why does the finished product have to be a closed shape or ellipse? Just have maximum draw time limits. You already have the 2 ellipses you're multiplying, you're just transforming one with respect to the other. Also, Chocolat Oreos image comes from an N-body system, not patched conics so it's obviously going to show more complex patterns. I still doubt the computation will be very intense though as it's just matrix multiplication of equal time points with a line connecting each point.

 

That all said, I doubt this feature will show up also. 

Note that the N-body system wouldn't make much of a difference compared to a stock system for that picture, as the difference for Hohmann transfers isn't much (in this scenario) and the orbits are elliptical just like in stock on an Earth centered inertial. But I do agree to the time button, or maybe even have a button that would increment the time based on orbital periods, but that's hard if the rendezvous is on an hyperbolic intersection, so maybe just a time slider. 

I also doubt that this feature will ever exist, but it would be really useful to have. 

[Incarnation of Chaos]

On 5/27/2021 at 4:34 AM, mcwaffles2003 said:

Why does the finished product have to be a closed shape or ellipse? Just have maximum draw time limits. You already have the 2 ellipses you're multiplying, you're just transforming one with respect to the other. Also, Chocolat Oreos image comes from an N-body system, not patched conics so it's obviously going to show more complex patterns. I still doubt the computation will be very intense though as it's just matrix multiplication of equal time points with a line connecting each point.

 

That all said, I doubt this feature will show up also. 

Keep in mind just traversing a matrix is a  O(N^2) operation for CPU code. Performing multiplication is a linear operation, but as you might have to traverse the matrix to get the required values multiple times for a single calculation... were approching levels of time complexity that hurts my brain.

[K^2]

14 minutes ago, Incarnation of Chaos said:

Keep in mind just traversing a matrix is a  O(N^2) operation for CPU code. Performing multiplication is a linear operation, but as you might have to traverse the matrix to get the required values multiple times for a single calculation... were approching levels of time complexity that hurts my brain.

I'm not sure where you're even going with this. If we're restricting the discussion to SoI orbits, and we are simply adding an extra frame of reference, you don't need to recompute anything. You simply draw a tessellated orbit for several revolutions, or within convenient time frame, and then pass a time parameter along with each and a parametrized transform matrix. The matrix multiplication in question is a normal 4x4 transform. There is nothing here that scales with any sort of N. Position of each point is essentially closed form to within your method for computing trig functions and anomaly. This is so cheap to run on the shader that it's not even worth discussing as added complexity.

If you are not convinced, I can put together a WebGL example that does this in real time without even registering as a GPU load.

[Incarnation of Chaos]

23 minutes ago, K^2 said:

I'm not sure where you're even going with this. If we're restricting the discussion to SoI orbits, and we are simply adding an extra frame of reference, you don't need to recompute anything. You simply draw a tessellated orbit for several revolutions, or within convenient time frame, and then pass a time parameter along with each and a parametrized transform matrix. The matrix multiplication in question is a normal 4x4 transform. There is nothing here that scales with any sort of N. Position of each point is essentially closed form to within your method for computing trig functions and anomaly. This is so cheap to run on the shader that it's not even worth discussing as added complexity.

If you are not convinced, I can put together a WebGL example that does this in real time without even registering as a GPU load.

They're not doing tessellation for drawing orbits on the GPU, per the developer.

It's all on the CPU, hense my concern.

Link to relevant reply-

https://forum.kerbalspaceprogram.com/index.php?/topic/201736-developer-insights-9-–-orbit-tessellation/&do=findComment&comment=3961987

Edited June 5, 2021 by Incarnation of Chaos

[K^2]

43 minutes ago, Incarnation of Chaos said:

They're not doing tessellation for drawing orbits on the GPU, per the developer.

It's all on the CPU, hense my concern.

Nobody said anything about tessellating on the GPU.  You send a tessellated orbit in SoI coordinates to the GPU and transform to body coordinates in the vertex shader. It's one 4x4 matrix multiply per vertex. That's basically free.

[Incarnation of Chaos]

1 hour ago, K^2 said:

Nobody said anything about tessellating on the GPU.  You send a tessellated orbit in SoI coordinates to the GPU and transform to body coordinates in the vertex shader. It's one 4x4 matrix multiply per vertex. That's basically free.

Sorry, i thought you used "Shader" to mean something running on the GPU <.<

Then as long as it doesn't have to loop through the matrix and grab values, it wouldn't perform poorly. Which from reading over your approach, looks like it avoids that entirely.

[K^2]

43 minutes ago, Incarnation of Chaos said:

Sorry, i thought you used "Shader" to mean something running on the GPU <.<

The shader does run on the GPU. But it doesn't handle tessellation. I mean, it can - you can totally do pixel-perfect conic sections on GPU, but relevant approaches becomes kind of hardware-specific, and I honestly have no idea how much pain it'd be to even set it up on Unity... So lets skip that mess. We already know that Intercept went with CPU tessellation. So there is already an algorithm that takes orbital elements of given ship and turns it into a list of points which will be connected with straight line segments to form an approximation of the curve on the screen. We take that list of points - if it goes to the boundaries of SoI, take it as is; if it closes on itself, you can repeat this list several times to cover several orbits. In SoI coordinate system, the points are going to be the same for several orbits, so we just copy the list. Then this list of points is sent to the GPU to get drawn to the screen and this is where vertex shader can do its magic.

Normally, you just want to transform verts from SoI space to screen space. This is done with two (sometimes three*) matrix multiplications. First takes the points from SoI space to camera space, second applies projection transform to fit the frustum of the screen space. To make it relative to the body, we need to add one more matrix multiplication to take points from SoI space to body space. Rest of the math stays the same. The kicker is that this new matrix isn't the same for every single point - it's time dependent. Which means we have to pass time index with each spline vertex (easy, we need it for computations anyways) and to compute the relevant transform matrix - that will cost you a sin/cos computation. Using lookup table and refining with series expansion, you can get a sin/cos in just a few iterations, so we're looking at a cost of maybe an extra dozen multiply/add operations, and then you do the matrix multiplication.

For comparison, something very similar is done for things like motion blurs and light trails in a lot of games. A tech artist who's a bit more on the techier side will have no trouble setting up a vertex shader for this in Unity or any other engine.

 

* Ok, just for the sake of completeness, the SoI -> Camera transformation could be baked as pair of matrices. Soi -> World and World -> Camera. But I doubt it, because that can result in huge loss of precision. Good practice is to pre-multiply these transforms in CPU before handing them off to shader. You can still lose precision here, but because the error is the same for the entire frame, it doesn't cause distortion or clipping effects. So I'm almost sure we're talking about just two matrices here. One to transform to camera space and one for projection.

[Incarnation of Chaos]

2 hours ago, K^2 said:

The shader does run on the GPU. But it doesn't handle tessellation. I mean, it can - you can totally do pixel-perfect conic sections on GPU, but relevant approaches becomes kind of hardware-specific, and I honestly have no idea how much pain it'd be to even set it up on Unity... So lets skip that mess. We already know that Intercept went with CPU tessellation. So there is already an algorithm that takes orbital elements of given ship and turns it into a list of points which will be connected with straight line segments to form an approximation of the curve on the screen. We take that list of points - if it goes to the boundaries of SoI, take it as is; if it closes on itself, you can repeat this list several times to cover several orbits. In SoI coordinate system, the points are going to be the same for several orbits, so we just copy the list. Then this list of points is sent to the GPU to get drawn to the screen and this is where vertex shader can do its magic.

Normally, you just want to transform verts from SoI space to screen space. This is done with two (sometimes three*) matrix multiplications. First takes the points from SoI space to camera space, second applies projection transform to fit the frustum of the screen space. To make it relative to the body, we need to add one more matrix multiplication to take points from SoI space to body space. Rest of the math stays the same. The kicker is that this new matrix isn't the same for every single point - it's time dependent. Which means we have to pass time index with each spline vertex (easy, we need it for computations anyways) and to compute the relevant transform matrix - that will cost you a sin/cos computation. Using lookup table and refining with series expansion, you can get a sin/cos in just a few iterations, so we're looking at a cost of maybe an extra dozen multiply/add operations, and then you do the matrix multiplication.

For comparison, something very similar is done for things like motion blurs and light trails in a lot of games. A tech artist who's a bit more on the techier side will have no trouble setting up a vertex shader for this in Unity or any other engine.

 

* Ok, just for the sake of completeness, the SoI -> Camera transformation could be baked as pair of matrices. Soi -> World and World -> Camera. But I doubt it, because that can result in huge loss of precision. Good practice is to pre-multiply these transforms in CPU before handing them off to shader. You can still lose precision here, but because the error is the same for the entire frame, it doesn't cause distortion or clipping effects. So I'm almost sure we're talking about just two matrices here. One to transform to camera space and one for projection.

And that's where i got it wrong, i didn't even think you'd be able to use a lookup table. Great breakdown as always.

[mcwaffles2003]

Well... I learned a lot thanks to both of you.