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

21–30 of 84 posts

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#21

Post by jhgb »

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…

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

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#22

Post by jhgb »

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!

Apollo 8 proved it possible, actually. ;) The onboard sextant worked perfectly.

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#23

Post by modeless »

skykooler wrote: post #19
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 physic…

That's interesting. It doesn't sound that simple though, I imagine there are some gotchas with that. They are probably constrained by what Unity allows.

In my custom engine I did the world to camera transform for each object on the CPU in double precision, essentially making the camera the origin for all subsequent single precision computations on the GPU. That works for small objects and even large objects that are split into small parts, like a planet split into LOD terrain tiles. But it didn't work for orbit lines because they are a single object at planet scale that you can zoom in on to see at human scale (I didn't have an adaptive tesselation system like the one in the article).

It also wouldn't have worked for galaxy scale, where even double precision wouldn't be enough. I don't know exactly what Celestia and similar "entire universe" apps do. Emulated quad precision floating point?

Edit: I just realized that you are talking about precision issues with the physics engine, while I'm talking about precision issues in the rendering engine. Related but slightly different. Physics engines aren't constrained by GPUs and can use double precision throughout. But they often have stability issues even in normal circumstances so I can certainly imagine that solar system scales would be a problem even in double precision.

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#24

Post by nuclearsugar »

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…

Creating astronomy visualizations often involves all sorts of fun tricks. I work in a planetarium as a 3D animator and each day has interesting unique challenges. Indeed we have to remain mindful of not pushing Maya too hard when it comes to series of scale.

We use fluids as a way to create 3D nebulae that can be flown through. https://thefulldomeblog.com/2013/08/20/the-nebula-challenge/

Or if you constrain the fluid into a sphere, then you have a dynamic volumetric sun. https://thefulldomeblog.com/2013/07/30/customizing-a-close-u...

When needing to fly through a star field, relying on particle sprites is an easy way to quickly render thousands of stars. https://thefulldomeblog.com/2013/07/03/creating-a-star-field...

Background stars are achieved by point-constraining a poly sphere to the camera. Having a poly sphere allows for easy manipulation to create realistic diurnal motion. https://thefulldomeblog.com/2013/11/13/background-stars-v2/

Flying through a galaxy field can be achieved with loads of galaxy images mapped to poly planes. For galaxies that are seen edge on, we sometimes add more detail by emitting fluid from the image colors. https://thefulldomeblog.com/2013/07/16/flying-through-a-gala...

Simulating the bands of Jupiter is tricky but I've done some experiments with 2D fluids. https://thefulldomeblog.com/2014/01/30/jupiter-bands-simulat...

And of course since the visuals are rendered for a planetarium dome, we gotta render using a fisheye camera. These days all render engines support fisheye, but 10 years ago it was a different story. https://thefulldomeblog.com/2019/09/07/exploring-render-engi... https://thefulldomeblog.com/2013/06/28/fisheye-lens-shader-o... https://thefulldomeblog.com/2013/07/23/stitching-hemicube-re...

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#25

Post by modeless »

jhgb wrote: post #21
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…

> 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 probably without niceties like operator overloading.

It's not required for space rendering, as once everything is in camera coordinates you no longer have any visible precision issues (as long as you are using a float reverse Z buffer). You just have to be careful to make sure your world to camera transforms are done on the CPU, and you break large objects like planets into small LOD chunks with their own local coordinate systems, which you need to do anyway.

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#26

Post by zlsa »

nuclearsugar wrote: post #24
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…

Creating astronomy visualizations often involves all sorts of fun tricks. I work in a planetarium as a 3D animator and each day has interesting unique challenges. Indeed we have to remain mindful of not pushing Maya too hard when it comes to series of scale. We use fluids as a way to create 3D nebulae that can be flown through. https://thefulldomeblog.com/2013/08/20/the-nebula-challenge/ Or if you constrain the fluid…

I'm sure you've heard this before, but have you checked out Space Engine[0]? It has some pretty advanced features, like path animations and cubemap rendering. I'm not sure how well it'd integrate into existing workflows, but I've used it for creating high dynamic range skyboxes for spacecraft renders.

[0]: http://spaceengine.org/

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#27

Post by cridenour »

elil17 wrote: post #2

My biggest question: who the hell plays KSP without the orbit map interface?

I watched a streamer play KSP for the first time, not have the patience to learn orbits (at least on stream), just point at the Mun and go for it.

I was yelling at the screen that it wouldn't work, but somehow he made it there, though with the same delta-v he could have gone to Eve.

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#28

Post by exDM69 »

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?

If you want to texture a sphere, the cubesphere is the best way to draw. It is what you get when you subdivide a cube using slerp instead of lerp for interpolation.

Icosahedron doesn't work well if you have textures. The triangle topology near the poles lead to bad texturing.

Icosahedron may work better if you have a fully procedural pipeline and don't need to worry about square textures.

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#30

Post by m_mueller »

fy20 wrote: post #29

One of the things KSP taught me is that orbital mechanics aren't that complicated, but even so, pretty much all movies and TV shows about space were written by someone who doesn't even know the basics.

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...
Post reply on HN