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

41–50 of 84 posts

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#41

Post by esjeon »

teraflop wrote: post #8
esjeon wrote: post #4

I'm a bit puzzled here, after seeing the word "screen-space". I'm no game dev, but I know that there's tessellation shader for this very purpose. We can let the shader churn out more points on-demand in a separate step in the rendering pipeline. I think doing this in "screen-space" is a bit unnatural. (Just nitpicking.)

"Screen space" refers to the coordinate system. Regardless of whether you were doing tessellation on the CPU or the GPU, you would want to use screen coordinates to make your decisions about which segments to subdivide, because what you care about is the deviation of the rendered curve from its "ideal" path. A large error in world coordinates doesn't matter if it's so far from the viewpoint that it looks tiny. Tessel…

Thanks for the reply. I've written graphics code only on more-or-less lab environments, and have read many papers mentioning screen-space algorithms which trades off accuracy for other characteristics. Maybe I'm triggered by that. lol

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#42

Post by aw1621107 »

Dylan16807 wrote: post #20
teraflop wrote: post #16

Earlier quoted context omitted.

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 ext…

> 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".

KSP's most well-known n-body physics mod does precisely this. 1 integration step is performed every frame by default, but during warp an integration step is performed every 10 in-game seconds for vessels and every 35 minutes for bodies [0].

> 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.

The Keplerian curve no longer applies once you introduce additional influences, though, so it doesn't really matter how (in)frequently updates are applied for those other influences.

The approximation wouldn't be very good farther away from a body as well, as the difference in effect between the "most influential" and less-influential bodies would be smaller.

[0]: https://github.com/mockingbirdnest/Principia/issues/2247#iss...

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#44

Post by m_mueller »

dogma1138 wrote: post #40
m_mueller wrote: post #30

Earlier quoted context omitted.

Expanse season 1 was a nice exception to the rule, but I find that as the longer the show goes on the more it gets ignored. Missiles that fly into the sun at faster than light speeds...

The expanse still gets the physics right for the important scenes. Watching people stand for over a few days looking at a torpedo slamming into the sun would be boring. Space combat physics is still done very well.

I’d argue that it’s just an effect of lazy writing though. Deorbiting anything into the sun is a very expensive way to get rid of it. They showed instant proto molecule cleanup operations in another season - just use that again.

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#45

Post by gbrown_ »

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…

> yet GPUs don't support double precision well.

Are there GPUs without FP64 functionality at all? Or are you just referring to most consumer GPUs being built for FP32 performance over FP64?

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#46

Post by loa_in_ »

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 you mean the seam between Surface and Orbit frames of reference, then it's unavoidable. One measures velocity with the surface velocity vector added and one doesn't. The surface velocity vector is the linear velocity of ground due to planet rotation around it's own axis

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#47

Post by jhgb »

modeless wrote: post #25
jhgb wrote: post #21

Earlier quoted context omitted.

> 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. Could you do double-single computations on a GPU? (By that I mean something like double-double arithmetic, only with two singles instead of two doubles.)

Sure, with a performance penalty. Some GPUs do support double precision, though again at a performance penalty. You might run into issues with the fixed function parts of the GPU being single precision even on GPUs that support double precision types in shaders, depending on how you do things. Also, shading languages probably don't have nice libraries for double single precision so you'd have to roll your own, and pr…

If I recall correctly, on a CPU, the penalty of doing "double-X" is something like 1:7 or so compared to just doing X. On most consumer GPUs, the penalty of doing doubles instead of singles would be a 1:24 or 1:32 these days, wouldn't it? So there should still be a fourfold speedup or so. Mixed binary operations with one single and one double-single should be cheaper, whenever applicable.

As for "rolling your own", this is a compiler transformation, effectively. So it may depend on your workflow whether it's painful or not.

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#48

Post by Robadob »

gbrown_ wrote: post #45
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…

> yet GPUs don't support double precision well. Are there GPUs without FP64 functionality at all? Or are you just referring to most consumer GPUs being built for FP32 performance over FP64?

It's not that GPUs don't support fp64, it's that for domestic gamer GPUs fp64 arithmetic is normally ~1:32 performance of fp32 arithmetic.

e.g. 1080gtx

    FP16 (half) performance
    138.6 GFLOPS (1:64)
    FP32 (float) performance
    8.873 TFLOPS
    FP64 (double) performance
    277.3 GFLOPS (1:32)
e.g. 3090rtx

    FP16 (half) performance
    35.58 TFLOPS (1:1)
    FP32 (float) performance
    35.58 TFLOPS
    FP64 (double) performance
    556.0 GFLOPS (1:64)
Only generally 'tesla' class cards targeted at super computers have a 1:2 ratio (e.g. v100, A100, Titan V). Note, I believe Titan V is the only Titan series GPU with good double performance, as the Volta architecture was never available to Geforce GPUs.

https://www.techpowerup.com/gpu-specs/geforce-gtx-1080.c2839

https://www.techpowerup.com/gpu-specs/geforce-rtx-3090.c3622

https://www.techpowerup.com/gpu-specs/tesla-v100-sxm3-32-gb....

https://www.techpowerup.com/gpu-specs/a100-sxm4-80-gb.c3746

https://www.techpowerup.com/gpu-specs/titan-v.c3051

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#49

Post by Dylan16807 »

aw1621107 wrote: post #42
Dylan16807 wrote: post #20

Earlier quoted context omitted.

> 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 ext…

> 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". KSP's most well-known n…

> The Keplerian curve no longer applies once you introduce additional influences, though, so it doesn't really matter how (in)frequently updates are applied for those other influences.

It depends on how well you can simplify the math. I would imagine that instead of an n body calculation it's lot simpler to calculate the influence from one body plus one unchanging vector, but I've never tried it.

> The approximation wouldn't be very good farther away from a body as well, as the difference in effect between the "most influential" and less-influential bodies would be smaller.

Not a problem because if you're not close to anything then your orbit won't be chaotic.

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#50

Post by db48x »

aw1621107 wrote: post #42
Dylan16807 wrote: post #20

Earlier quoted context omitted.

> 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 ext…

> 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". KSP's most well-known n…

I found Principia’s code to be quite nice to read too; I recommend it next time you have a lazy Sunday afternoon.
Post reply on HN