Developer Insights #9 – Orbit Tessellation

[Bej Kerman]

2 hours ago, HebaruSan said:

2 hours ago, SpaceFace545 said:

Maybe we could see some gameplay instead of proof that you guys know what you are doing. We get it, you guys understand how to make a game.

Maybe we could let the people who enjoy this post, enjoy it?

I don't get how their suggestion to post what should be the result of several years is a suggestion that you should stop enjoying this post.

[Dr. Kerbal]

I don't care what they say about other games.

KSP2  might blow away STEAM. Its already one of Steam's most wishlisted games. Man. All the guys from KSP1 are going to be like ancients when KSP2 comes out. Man, I havent even been KSP for about a 1 year and 4 months. 

[PlutoISaPlanet]

The fact the devs made this from scratch just to show us what they have done tells me they truly care.

[HebaruSan]

7 minutes ago, Bej Kerman said:

I don't get how their suggestion to post what should be the result of several years is a suggestion that you should stop enjoying this post.

They're diverting an interesting thread with comments that are less interesting. This degrades the quality of the discussion.

[Bej Kerman]

7 minutes ago, HebaruSan said:

15 minutes ago, Bej Kerman said:

I don't get how their suggestion to post what should be the result of several years is a suggestion that you should stop enjoying this post.

They're diverting an interesting thread with comments that are less interesting. This degrades the quality of the discussion.

I don't know why sceptical comments have to be gatekeeped. Remember when sceptics were laughed out of the No Man's Sky community before launch?

[Johannes]

42 minutes ago, minerbat said:

this is not the game, just a quick and dirty presentation. there is no reason to make such detail on this, it's just extra work

Yep! When first prototyping new tech like this it can often be faster to iterate on it in isolation in a separate project until it is ready, and since I already had that it's what I used to make these visuals. The 'icons' here are just 3D spheres that scale to a specific size in screen space (which was trivial to do with the drawing library I was using), so there is really no logic that prioritizes one over the other.

You may have heard of the term 'separation of concerns' in programming. The portion of what you see here that can be found in the game is just the equivalent of the GenerateParametricPoints function in the post: It's a dedicated class that you give parametric functions for position, and optionally color and thickness, as well as anything else it might need such as the camera it should use, and it is only responsible for generating the points (and some additional metadata).

How those points are actually drawn to the screen once you have them is the responsibility of a whole different bit of code that is far more basic here than it is in the actual game (and that could probably fill a blog post all on its own).

Edited April 15, 2021 by Johannes

[Poodmund]

Very cool! I hope bodies without PQS-meshes occlude orbit line rendering in KSP2, its always been a bit of a shame that they render in front of Gas Giants in KSP1.  

EDIT: I hope the 2nd part of my post doesn't detract from the fact that I think this is very, very cool!

Edited April 15, 2021 by Poodmund

[HebaruSan]

4 minutes ago, Johannes said:

and optionally color and thickness

Ooh, so if you have a line that's really stripey in a particular region, that might generate more tesselations even if it was straight (and so the triangles are tiny)?

Anything to share regarding how to avoid false optimizations? X, X+356°, and X+358° are going to have a pretty small triangle between them, but if the algorithm ever generated three such points, it might simplify a circle down to a tiny line. One way to deal with that is to make sure you have enough well-distributed starting points, but did you find anything else to deal with the more general form of this problem (e.g., if my stripey line coincidentally happens to have the same color at two currently adjacent points despite going through many others in between)?

(If the answer is that it's a trade secret, don't sweat it. Just idly curious.)

[Dr. Kerbal]

32 minutes ago, PlutoISaPlanet said:

The fact the devs made this from scratch just to show us what they have done tells me they truly care.

Yes. If I was making this I would've given up by now.

9 minutes ago, Johannes said:

You may have heard of the term 'separation of concerns' in programming. The portion of what you see here that can be found in the game is just the equivalent of the GenerateParametricPoints function in the post: It's a dedicated class that you give parametric functions for position, and optionally color and thickness, as well as anything else it might need such as the camera it should use, and it is only responsible for generating the points (and some additional metadata).

Thanks for the clarrification. 

[Johannes]

20 minutes ago, HebaruSan said:

Ooh, so if you have a line that's really stripey in a particular region, that might generate more tesselations even if it was straight (and so the triangles are tiny)?

Anything to share regarding how to avoid false optimizations? X, X+356°, and X+358° are going to have a pretty small triangle between them, but if the algorithm ever generated three such points, it might simplify a circle down to a tiny line. One way to deal with that is to make sure you have enough well-distributed starting points, but did you find anything else to deal with the more general form of this problem (e.g., if my stripey line coincidentally happens to have the same color at two currently adjacent points despite going through many others in between)?

(If the answer is that it's a trade secret, don't sweat it. Just idly curious.)

I don't think I can get into too much detail there, but you've got some good intuition. Only position is considered in the smoothness heuristic. Color and thickness are just stored after a point is generated using its parameter. Any effect other than a smooth gradient would probably be best done in a shader on the mesh ultimately generated from the points. But you are right, in some edge cases such as when points are too close to co-linear you may need more than just the triangle heuristic to get enough points for it to look good

Edited April 15, 2021 by Johannes

[Vanamonde]

You can't please everybody, but let's please skip an argument about whether or not this is the aspect of development the devs should have shared, and whether or not others are wrong for wanting to see something else. Either enjoy this post or move on to other discussions. 

[Kerminator K-100]

Extra excited for KSP2 launch!

@Johannes this exactly the type of dev diary I like to see! Can the programming team do more of these? This one was super interesting to me and I would love to see more of the technical challenges that KSP2 faces. I may be biased but I definitely think mechanics beat visuals in video game development (after all I play ksp!). These types of posts show me that the team cares and isn't just trying to wow me with cool terrain, clouds, and big colony parts.

I also thought it was interesting that when you look away from the orbit, it changes the detail. I understand about stuff like ambient occlusion and the need for frames but its still really weird to see it in action, and to know that when you aren't looking things change and disappear. Its kind of the man behind the curtain of video games. Also it can freak you out if you aren't careful. What if nothing exists until I look at it!

Anyway great post! Thanks for the update!

[Dr. Kerbal]

57 minutes ago, Vanamonde said:

You can't please everybody, but let's please skip an argument about whether or not this is the aspect of development the devs should have shared, and whether or not others are wrong for wanting to see something else. Either enjoy this post or move on to other discussions. 

At least we get a dev post. And I enjoy this! Very interring and informative. (But to be honest I enjoy everything from slow snails to epic spaceships so Im not the one to judge.)

14 hours ago, Intercept Games said:

All orbits are to scale and celestial bodies are a constant screen size to make them easy to see.

Nice!

Edited April 15, 2021 by Dr. Kerbal
I tried humor. Not my thing. :(

[Guest]

5 hours ago, Johannes said:

snip

yes another KSP team account to follow

[Anth]

@Johannes Incredible Post. I would love to see more of these types of dev posts.

[Wubslin]

This is really cool! I suppose something I never think about is the way these optimizations stop being applied when the camera looks away from them. 

Just a question though, you guys wouldn't happen to plan on mapping parameters along curves that aren't conic sections, would you? Because if you were, it would be really cool to see what you use to identify motion along that curve when simple true anomaly off a single center point no longer works. I suppose you wouldn't need a parameter if your ship weren't on a function-defined curve and instead a vector sum of a couple of nearby gravitational pulls determined your motion at any instant in time...

I kid. To need a system like that you'd need to have something like two really big rocks really close together which is bananas. 

[justspace103]

VERY AWESOME! Here's a meme for your hard work @Intercept Games 

[Alexoff]

Didn't think drawing a circular orbit in 2021 would be a challenge

[prestja]

3 hours ago, Johannes said:

drawing library I was using

What drawing library are you using?

[Spaceman.Spiff]

3 hours ago, Johannes said:

I don't think I can get into too much detail there, but you've got some good intuition. Only position is considered in the smoothness heuristic. Color and thickness are just stored after a point is generated using its parameter. Any effect other than a smooth gradient would probably be best done in a shader on the mesh ultimately generated from the points. But you are right, in some edge cases such as when points are too close to co-linear you may need more than just the triangle heuristic to get enough points for it to look good

can we make custom orbit line colors?

[HebaruSan]

3 hours ago, Johannes said:

Any effect other than a smooth gradient would probably be best done in a shader on the mesh ultimately generated from the points.

Ahh, good point, a shader could make a straight line as stripey as you wanted with none of the risks or corner cases of trying to do it with geometry. Better performance, too.

One more thought, if you expose this tesselation logic so mods can call it, you'll probably earn quite a few fans among mod authors.

[wasml]

4 hours ago, Johannes said:

a whole different bit of code that is far more basic here than it is in the actual game (and that could probably fill a blog post all on its own).

Next week?

[Johannes]

2 hours ago, Wubslin said:

Just a question though, you guys wouldn't happen to plan on mapping parameters along curves that aren't conic sections, would you?

The tessellation algorithm can work for anything you can define as a parametric function that is contiguous between a given start and end parameter.

2 hours ago, Alexoff said:

Didn't think drawing a circular orbit in 2021 would be a challenge

The truth may surprise you!

1 hour ago, prestja said:

What drawing library are you using?

Since you asked, this one!

[Wubslin]

3 minutes ago, Johannes said:

The tessellation algorithm can work for anything you can define as a parametric function that is contiguous between a given start and end parameter.

Right, but what happens when, say, there is no continuously defined function to map a parameter onto? I was trying to imply that the restricted 3-body situation around Rask and Rusk might require iteratively solving for Newton's law every X time steps, which precludes knowing your orbit far into the future with a high degree of accuracy. What can be done in that situation?

 

 

[Makc_Gordon]

3 hours ago, Alexoff said:

Didn't think drawing a circular orbit in 2021 would be a challenge

Don't forget who is developing the game