Live data from Hacker News

Orbit Tessellation developer diary for Kerbal Space Program 2

kerbalspaceprogram.com

1–10 of 84 posts

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

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

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#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 only send the GPU coordinates it can handle, or your 3D models will get crunched by precision errors.

Another one is that a planet sphere renderer will often tesselate the sphere into quads in lat-lon space. Of course the quads are split into two triangles for rendering. However, at the poles, one of the triangles has zero area because two of its vertices are the same, the pole. Then when you texture map that "quad" with a square texture, half of the texture is not shown, and you get visible seams (Google Earth suffers from this artifact, or at least it did in the past). What's less obvious is that this problem is present to a lesser extent in every quad on the sphere, because the triangle with the horizontal edge nearer the pole is smaller than the other, so half of the texture is stretched and half is shrunk. The fix is to use homogeneous texture coordinates.

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

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

Tessellation shaders are useful for processing polygonal geometry with many thousands of polygons, but they have a fairly constrained programming model. And as you can see from the example images, rendering a high-quality orbit path only requires a few dozen vertices. The performance benefit from moving that computation into a tessellation shader is likely to be insignificant compared to the additional complexity and overhead.

Re: Orbit Tessellation developer diary for Kerbal Space Program 2

#9
post #7
post #2

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

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