Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Orbit Tessellation developer diary for Kerbal Space Program 2

kerbalspaceprogram.com

Post reply on HN
Print view View original

11–20 of 84 posts

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#11

Post by DavidSJ »

elil17 wrote: post #9
DavidSJ wrote: post #7

Earlier quoted context omitted.

I've done this for fun to see if I could get to the Mun only looking out the window in the crew cabin. (I succeeded!)

That’s what I was imagining but I would have thought it impossible. Very impressive!

Thanks! It requires some planning.

It's been ~7-8 years, but I guess I probably figured out what trans-Munar injection velocity I needed and roughly what phase angle I wanted the Mun at (these are some basic astrodynamical calculations). You can determine velocity precisely from instruments and phase angle well enough from visuals that you pretty much guarantee a rendezvous.

Once you enter the Munar sphere of influence, just wait until periapsis and start killing velocity. You'll want a table prepared (somewhat conservatively, to give yourself room for fine-tuning) of what your velocity should be at a given altitude to make sure that you land at 0 m/s without using too much propellant, and remember to adjust the "sea level" altitudes for ground level before your radar altimeter kicks in. I guess the hard part is making sure you land on something flat, but you can impart some lateral impulse if necessary until you see a good landing spot below.

Getting back is similar, but the calculations are a bit simpler.

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#12

Post by deepsun »

My biggest problem with trajectories in KSP was that they flip non-continuously once the trajectory passes through a sphere of influence. I believe it would be much clearer and easier if trajectories were continuously changing but just marked once they pass through a SoI.

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#13

Post by wwarren »

modeless wrote: post #6

Space rendering is full of interesting problems like this. Another one is that single precision floating point doesn't have enough precision to represent both planet scale and human scale in the same coordinate system (let alone solar system scale or galaxy scale), yet GPUs don't support double precision well. So you have to make sure that you do calculations needing high precision on the CPU in double precision and…

Can’t we use an icosahedron for a better sphere?

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#14

Post by modeless »

wwarren wrote: post #13
modeless wrote: post #6

Space rendering is full of interesting problems like this. Another one is that single precision floating point doesn't have enough precision to represent both planet scale and human scale in the same coordinate system (let alone solar system scale or galaxy scale), yet GPUs don't support double precision well. So you have to make sure that you do calculations needing high precision on the CPU in double precision and…

Can’t we use an icosahedron for a better sphere?

Yes, and there are many other tessellations you can use, if you texture it with a single texture. But you can't texture a whole planet with one texture if you allow zooming from planet to human scale, the texture would be terabytes. You must tile the sphere with textures that are loaded on demand, and textures are square, so it makes sense to divide the sphere into quads (actually a quadtree for zooming).

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#15

Post by [deleted] »

modeless wrote: post #6

Space rendering is full of interesting problems like this. Another one is that single precision floating point doesn't have enough precision to represent both planet scale and human scale in the same coordinate system (let alone solar system scale or galaxy scale), yet GPUs don't support double precision well. So you have to make sure that you do calculations needing high precision on the CPU in double precision and…

[deleted]

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#16

Post by teraflop »

deepsun wrote: post #12

My biggest problem with trajectories in KSP was that they flip non-continuously once the trajectory passes through a sphere of influence. I believe it would be much clearer and easier if trajectories were continuously changing but just marked once they pass through a SoI.

If I'm correctly understanding what you mean, I'm fairly sure that's a deliberate optimization/design choice.

In the real world, a spacecraft or other object in orbit around Earth is also being constantly influenced by other celestial bodies, especially the sun and moon. Over short timescales this causes the spacecraft's orbital parameters to slowly drift; over longer timescales, it means the long-term position and fate of an object is chaotic and unpredictable. The behavior near the "boundary" between two spheres of influence is just a situation where these perturbations are more noticeable.

KSP only implements two-body physics, so a spacecraft is only affected by the gravity of one celestial body at any given time. This allows you to put something in orbit and know that it will stay there without you needing to constantly check on it and perform stationkeeping.

It's also the key simplification that makes "time warp" possible, since two-body orbits have closed-form solutions. To implement time warp with many-body physics, you would need to either keep the integration step size the same and drastically increase the amount of computation, or increase the step size and suffer from extreme inaccuracy, causing objects to crash or fly off into space.

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#17

Post by Groxx »

deepsun wrote: post #12

My biggest problem with trajectories in KSP was that they flip non-continuously once the trajectory passes through a sphere of influence. I believe it would be much clearer and easier if trajectories were continuously changing but just marked once they pass through a SoI.

When you do that, you have to start specifying what reference-point you're looking from. And then regardless of what you choose, you get these awesomely-weird spiraling / spirograph-ing orbits in some cases, e.g. like Principia shows https://www.youtube.com/watch?v=eU-kLLeE7n0

The non-continuous flip lets them keep orbits exclusively centered around the you're-most-likely-orbiting-this thing, which makes them all look "normal" and the same. Though I would like to be able to see either option in the stock game - they both have their uses.

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#18

Post by Uehreka »

elil17 wrote: post #9
DavidSJ wrote: post #7

Earlier quoted context omitted.

I've done this for fun to see if I could get to the Mun only looking out the window in the crew cabin. (I succeeded!)

That’s what I was imagining but I would have thought it impossible. Very impressive!

Here’s a recording of another guy doing it to “Ride of the Valkyries”: https://youtu.be/iXYGo9KO2nI

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#19

Post by skykooler »

modeless wrote: post #6

Space rendering is full of interesting problems like this. Another one is that single precision floating point doesn't have enough precision to represent both planet scale and human scale in the same coordinate system (let alone solar system scale or galaxy scale), yet GPUs don't support double precision well. So you have to make sure that you do calculations needing high precision on the CPU in double precision and…

KSP's approach to the precision problem is surprisingly simple: whenever you get more than two kilometers away from the origin, move the entire universe two kilometers so that the location of your craft, and all the physics-relevant computations on it, have small numbers as coordinates.

(This fix was known as Krakensbane: it solved a bug known as the Deep-Space Kraken, which was essentially that floating-point physics inaccuracies would tear your ship apart when you got much further than the moon or so, before it was implemented.)

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#20

Post by Dylan16807 »

teraflop wrote: post #16
deepsun wrote: post #12

My biggest problem with trajectories in KSP was that they flip non-continuously once the trajectory passes through a sphere of influence. I believe it would be much clearer and easier if trajectories were continuously changing but just marked once they pass through a SoI.

If I'm correctly understanding what you mean, I'm fairly sure that's a deliberate optimization/design choice. In the real world, a spacecraft or other object in orbit around Earth is also being constantly influenced by other celestial bodies, especially the sun and moon. Over short timescales this causes the spacecraft's orbital parameters to slowly drift; over longer timescales, it means the long-term position and f…

> It's also the key simplification that makes "time warp" possible, since two-body orbits have closed-form solutions. To implement time warp with many-body physics, you would need to either keep the integration step size the same and drastically increase the amount of computation, or increase the step size and suffer from extreme inaccuracy, causing objects to crash or fly off into space.

It makes things nicer at extremely high time warps, but it's not necessary. It's not like you need to update orbits nearly as often as part physics. The max time warp is 100000x, and at that speed if you updated orbits every 10 game seconds that would only be 400 calculations per tick, per craft. So without that simplification you might need a smaller cap on satellite swarms, or a max speed of 10000x, but time warp would still be well inside the realm of "possible".

Edit: You could probably get processor use really low by using an exact curve for the most influential object and a very slowly updated offset for other influences.

Post reply on HN