KSP Loading…: Leading up to something special

[UomoCapra]

Welcome to our official newsletter, KSP Loading…! If you want to learn about all the current developments of the KSP franchise, then this is the place to be!

And now, let’s talk about everything KSP!

Kerbal Space Program Update 1.12 on PC

Coinciding with the game’s 10th anniversary, Kerbal Space Program is getting ready for its 12th major free update since its official release, and it’s going to be epic! This update will be packed with brand new content such as new parts, features, revamps, and more! Buckle up, and let’s learn about some of the content that will be included in this upcoming update.

Eeloo and Pol Texture Revamps

With update 1.12, our effort to revamp all the celestial bodies within the Kerbal solar system will finally come to an end. Eeloo, the distant frozen dwarf planet, and Pol, the smallest natural satellite of Jool, are now looking better than ever with new high-quality textures & shaders. Surely many astronauts will take this opportunity to revisit them and explore what lies within these remote destinations. 

Revamped and Rotating Docking Ports

All the docking ports have gotten a well deserved aesthetic revamp. Among the bundle of requested features & quality of life additions we’re including in the 1.12 update, we are giving players the ability to rotate docking port collars added to docking ports. Lining up attached craft perfectly has never been easier!
 

New Solar Panels

This update will also include 4 brand new photovoltaic panels, including enhanced versions of the SP and OX-4 series, but also two large circular retractable solar panels with very cool deployment methods.

SP-10L 1x5 Photovoltaic Panels

This large retractable solar panel is an enhanced version of the SP series. With a five fold increased solar array area, the SP-10L will provide improved electrical charge generation. This solar panel also includes a case to protect this sensitive technology when it is not being used.

OX-10L 1x5 Photovoltaic Panels

The OX-10L 1x5 is a larger version of the OX-4 series of solar panels. It includes advanced heat radiators, and a deploying bracket to keep the panels safe when launching, although these panels are not retractable once deployed, so beware…

OX-10C Photovoltaic Panels

The crown jewel of the new circular retractable solar panels, the OX-10C provides a great output of electrical charge with a very decent solar array area. When folded it is compact and easy to transport, but although it deploys very graciously, it won’t retract back.

SP-10C Photovoltaic Panels

The SP-10C photovoltaic panel also has a circular design that folds itself on command, making it an excellent alternative if you’re looking for versatility.

 

Ground Anchor

The Ground Anchor is a brand new element in KSP, that when paired with EVA construction, will give players the ability to anchor their vessels to the ground or create a solid foundation for bases.

The deployable ground anchor will work as other deployable parts, so it will have to be put into a Kerbal’s inventory and then use the deploy functionality to have it successfully anchor itself to the ground in order to build a base from. 

KSP 2

Kerbal Space Program 2 has also had a few developments since our last KSP Loading. 

For instance, last week we released the third episode of the KSP 2 feature series, which delves into Intercept Games' mission to onboard the next generation of space industry experts with new tutorials, UI/UX improvements, quality of life features, and more.

Additionally, in the past few months we have released two additional dev diaries for KSP 2, including a very interesting and informative look into what a game producer actually does in the development process of a title.  

On 2/11/2021 at 4:00 AM, Intercept Games said:

Hi, friends! I’m Nate Robinson, senior producer on the KSP2 team, and I watched a lot of Apollo 13 as a kid – to the point that I practically wore out our family’s VHS copy.

Naturally, I always imagined myself in the role of astronauts Jim Lovell, Fred Haise, and Jack Swigert. Every 90s kid wanted to go to Space Camp, become an astronaut, and fly on the Space Shuttle, and I was no different.

But a funny thing happened a couple of decades later when I watched the film again as an adult: I didn’t find myself associating with the astronauts.

I, of course, had long ago moved on from any dreams of being an astronaut myself (I blame my poor vision, but trigonometry was truly where I gave up the ghost). Instead, I found myself far more engrossed in another role – that of flight director Gene Kranz.

Kranz, spends the entirety of the film not in space, but on the ground, trying to keep on top of an ever-shifting situation. He works feverishly with the bright minds around him for clever solutions to unpredictable problems and to keep everyone focused on the important goals in front of them.

In other words, he’s a game producer.

A game producer in their natural habitat.

The role of production in games is often tricky to define as it can vary from studio to studio and game to game, but it’s similar to that of a Product Owner or Project Manager in software development and other industries.

At Intercept, we have a team of three terrific* producers – including Fernanda Diaz and Paige Ketcham – whose job it is to ensure that development is running smoothly. We create and manage team processes, set goals and measure deliverables, coordinate cross-discipline efforts, prevent roadblocks, and do our best to keep everyone pointed in the same direction. Doing the job well requires strong communication, organization, multi-tasking, and leadership skills, along with a deep knowledge of the game you’re trying to make.

As you can imagine, it’s a lot to manage across a game with the mind-boggling size and scale of Kerbal Space Program (I have incidentally come to understand flight director Kranz’s evident chain-smoking habit), but it’s also the most rewarding job I’ve ever had. Establishing or optimizing a workflow that lets your team’s talented artists, engineers, or designers do their job even better may not sound sexy, but the reality is that it results in a much better game — and that never really gets old.

The KSP 2 dev team celebrates a successful milestone

On the KSP2 team, production’s fingerprints are everywhere. One day, we may be helping sort out the pipeline for creating new parts (What are the requirements for the part? Who will do the modelling and texturing? How many parts are needed and how much time do we have?) and another you may find us sort through bugs from a recent playtest (What is the priority of this issue? Who can help fix it on the dev team? When should it be looked at? Who replaced the Poodle engine with an actual dog?!). We are intimately involved in practically every aspect of development, which keeps us on our toes and no two days from being quite the same.

Of course, in order to get the answers to a lot of these questions and to ensure that the whole team is on the same page, we make use of another superpower of ours: Meetings. It’s a terrifying power, one that has been known to break lesser men (noted Kerbothropologist Paul Zimmer among them) and one we do not wield lightly. Running a meeting well is a criminally underrated skill and one that is essential to keeping a diverse, multi-discipline team moving forward hand-in-hand.

The normal dev-team response to me scheduling a meeting

Perhaps our most important responsibility, however, is managing the team’s short- and long-term tasks. Like much of the software world these days, the KSP2 team runs on a version of Scrum. Every three weeks, we gather our teams to review the previous cycle’s work, discuss how to improve our processes, and then get alignment on what the goals are for the next three weeks. There’s a lot of overhead involved in keeping a team of 30+ people busy, so we are constantly juggling a backlog of tasks in JIRA, our task-tracking software, so that the tasks are correctly prioritized and groomed (read: documented and clear).

For long-term planning, we build and maintain a development roadmap. A roadmap is simply a development schedule that lays out major milestones and when game features will be built. Some sections of the team — the part and planet artists, for instance — have their own roadmaps, but all development efforts are coordinated around a central roadmap for the entire project that is constantly being refined with adjustments to specific features and new estimates from the team itself. Even NASA’s Artemis team has a roadmap:

Though, where they’re going, they won’t need roads

We talk a lot about the roadmap on the production team because everything stems from it. No games are made by accident and one as complicated as Kerbal Space Program requires a lot of forward planning to ensure that our rocket leaves the launchpad on time and in one piece.

In future dev diaries, I hope we can give more insight into different aspects of production work as I barely scratched the surface of what is involved in this role. We didn’t get to cover our coordination with the marketing team or Squad, our instinctual need to document everything, or our unshakable convictions as to why Google Docs is a poor substitute for traditional Excel sheets! But I’ll just have to leave you with that tantalizing teaser — nothing gets people more excited for a dev diary than promises of spreadsheets!

… or maybe that’s just a producer’s thing.

 

 

*: I’m admittedly biased

View the full article

 

And, if you've ever wanted to dive into the technical side of KSP 2's development, this dev diary goes into the intricacies and challenges of drawing accurate orbits that look stellar, and how orbit tessellation turned out to be the solution to this problem in KSP 2.

On 4/15/2021 at 10:00 AM, Intercept Games said:

Hello all, I’m Johannes Peter – A programmer on Kerbal Space Program 2 – and I love solving interesting problems!

The problems we face in game development rarely have a single “correct” answer. The more specialized your game is, the more specialized your problems are, and the more creative your solutions need to be. As a rocketry simulator on an interplanetary scale, Kerbal Space Program has already tackled a wealth of unique programming challenges.

Today I want to share a solution I’ve worked on for a problem that is fairly unique to KSP: How to draw accurate orbits that look stellar regardless of where they’re viewed from?

I’ll briefly cover a standard approach for drawing orbits, touch on some of the issues with that approach, and then look at the solution that KSP2 is using now: screen space orbit tessellation.

This dev diary will get a bit into the technical side of KSP2’s development, with diagrams to help illustrate some of the core concepts. We will mainly focus on this test scene of Kerbin orbiting Kerbol:

Quick disclaimer:

• All visuals were created specifically for this dev diary, and are in no way representative of how anything may look in the final game.
  It’s just programmer art.
• All code, while functional, is simplified for clarity.
• All orbits are to scale and celestial bodies are a constant screen size to make them easy to see.

Orbital Trajectories in KSP

I hope it isn’t too hyperbolic of me to say, but KSP is all about orbits. Building, flying, and crashing rockets are all core to KSP’s identity, but if I had to describe KSP with one defining characteristic, it would be that it teaches you how orbits work on an intuitive level, just by playing it.

While there are definitely exceptions (you know who you are), most players depend on the Map View to plan their journeys from launchpad A to crater B, so being able to display lots of orbits without visual artifacts is critical.

What is an Orbit?

An orbit is the path that an object takes as it moves through space while under the gravitational influence of other objects around it. Real life orbits are chaotic and not deterministic. Without performing many small iterative calculations, it is generally not possible to say for certain where an object will be in space at an arbitrary point in time.

This is one of the reasons why KSP simplifies its orbital mechanics so that generally you’re only within the sphere of influence of one celestial body at a time. These kinds of orbits are known as Kepler orbits where position and velocity at any point on the orbit can be described using parametric equations. With a parametric equation we can plug in a parameter—like a time or an angle—and get an accurate position or velocity.

If a curve can be described as a parametric equation it is easy for us to draw.

Drawing Parametric Curves

In general, to draw a parametric curve we need to:

• Choose a start and end parameter, as well as how many points we want to generate.
• Generate the points by passing values into the parametric function that range from start to end.
• Draw a line between each consecutive pair of points.

For example, to draw a standard sine wave, we can use this parametric function:

Vector3 GetParametricPoint(float parameter)
{
    float x = parameter;
    float y = Mathf.Sin(parameter);
    return new Vector3(x, y, 0);
}

With that function we can use a start and end parameter to generate our points:

void GenerateParametricPoints(
    List<Vector3> points, float start, float end, int count)
{
    points.Clear();
    // Need at least two points to draw a line
    if(count < 2) return; 

    // Generate points using a parameter that
    // inclusively ranges from 'start' to 'end'
    float stepSize = (end - start) / (count - 1);
    for(int step = 0; step < count; ++step)
    {
        float parameter = start + stepSize * step;
        Vector3 point = GetParametricPoint(parameter);
        points.Add(point);
    }
}

And assuming that we have a function to draw a line between two points, we can finally draw the lines between the points we just generated:

void DrawParametricCurve(List<Vector3> points)
{
    int count = points.Count - 1;
    for(int step = 0; step < count; ++step)
    {
        Vector3 from = points[step];
        Vector3 to = points[step + 1];
        Draw.Line(from, to);
    }
}

Here is an example of what that looks like:

The green line is the ideal sine curve that we want to draw, and the blue line is the result of our GenerateParametricPoints and DrawParametricCurve functions.

Changing the start and end parameters (shown here in degrees) affects the position and length of the curve and the more points we generate the better the lines match the ideal curve.

Drawing an Orbit

Let’s assume that we have the following:

• A parametric equation of our orbit. The exact equation is outside the scope of this post, but for those curious, you can see better results if it uses the eccentric anomaly as its parameter.
• A start and an end parameter that we’ll step between. A full orbit’s parametric equation generally ranges from 0 to 2π radians, or 0 to 360 degrees.
• The number of points we want to generate. The default in KSP1 is 180 points for a full orbit.
• A graphics package to do the rendering. We need a way to draw a line between two points.

As with the sine wave, we generate points using parameters ranging from the start to the end value, and by increasing the number of points we generate, we get a smoother looking orbit:

Of course there’s a lot that I’m glossing over here, such as more efficient ways to draw lines than one at a time or other optimizations, but in a nutshell this is how orbits were drawn in KSP1.

Adding some Perspective

Evenly distributing the points of an orbit yields excellent results when viewed from far away, specifically when the camera is not close to the plane that the orbit is on.

However, in KSP you frequently view orbits from extremely flat angles. For example, when zoomed in close enough to see the moon of a planet, the orbit of the planet will be almost completely flat.

Let’s add the orbits of Kerbin’s moons Mun and Minmus to our example scene:

When we zoom in on Kerbin’s moons, we see sharp corners on Kerbin’s orbit. The orbit line also misses Kerbin by a significant margin.

Even though we generated Kerbin’s orbit with 180 points, the distance between two points is still about 5 times larger than Minmus’ entire orbit:

If we evenly distribute the points around the orbit, then with orbits as large as those in KSP we run into scenarios where there may not be enough points from the camera’s point of view to look smooth.

We could increase the point count, but we’ll quickly run into diminishing returns. Much of the orbit already looks smooth so adding points there would be a waste, while due to the angle of the camera other parts of the orbit don’t have enough points.

… What if we could add points only where they’re needed?

Screen Space Line Tessellation

If you have two points that were generated with a parametric equation you can generate a new point between them by averaging their parameters:

Vector3 pointA = GetParametricPoint(parameterA);
Vector3 pointB = GetParametricPoint(parameterB);

float parameterMid = (parameterA + parameterB) * 0.5f;
Vector3 pointMid = GetParametricPoint(parameterMid);

We can start with a small set of points and insert new ones by averaging their parameters. The curve becomes smoother each time we do this:

In computer graphics tessellation is the process of dividing geometry to make it smoother. We are effectively tessellating our parametric curve.

We really only care that the curve appears smooth on the screen, so we want to evaluate the smoothness of our points in screen space, where the X and Y coordinates correspond to the point’s screen position:

Vector3 screenA = camera.WorldToScreenPoint(pointA);
Vector3 screenB = camera.WorldToScreenPoint(pointB);
Vector3 screenC = camera.WorldToScreenPoint(pointC);

With our points in screen space, we can insert a new point between points A and B based on how smooth the curve is there. But how do we define ‘smoothness’?

Choosing a Smoothness Heuristic

A heuristic is a rule-of-thumb; a method for solving a problem very fast while being adequately accurate. We need a heuristic to efficiently decide if our points are ‘smooth enough’.

We’ve mentioned two heuristics so far:

• The distance between points. If points are visually close together then they’re less noticeable.
• The angle between points. The closer three points are to a straight line the less their middle corner stands out.

A convenient heuristic that incorporates both is the triangle area, which we can compute very quickly using the Shoelace formula:

float ComputeTriangleAreaXY(Vector3 a, Vector3 b, Vector3 c)
{
    return Mathf.Abs(a.x*b.y + b.x*c.y + c.x*a.y 
                   - a.y*b.x - b.y*c.x - c.y*a.x) * 0.5f;
}

If the triangle of a, b and c in screen space has an area larger than a given upper limit, then we insert a new point between a and b to smooth out the curve.

We evaluate our heuristic on every consecutive set of three points, until all points satisfy our heuristic, or we reach another end condition like how many points we have in total.

It can help to visualize the triangles:

Putting it all together

We can apply the triangle heuristic to our orbits, coloring each point based on the Iteration it was added in—red first, then orange, yellow, and so on:

The orbits are tessellated using the top-right camera and the turquoise lines show the viewing bounds of that camera. The top-left shows a close up of Kerbin and its moons.

The closer the camera moves to the orbit, the more iterations need to be performed to satisfy our heuristic, but we also use far fewer points overall because we only generate points where needed. For example the orbits of Mun and Minmus only generate new points when they become visible.

Here’s the original shot again with tessellation enabled and all debug drawing removed:

And that, in a nutshell, is how orbits are drawn in KSP2.

Closing Thoughts

When working on programming problems your first solution is rarely perfect, and it’s possible for your solution to have its own problems that you need to solve.

There is far more that went into the development of this feature that I’d love to share here, from implementation details like additional heuristics, culling optimizations and choosing the right data structure for efficient point insertions, to how this can be used for more than just Keplerian orbits, but this is enough for one post.

If you enjoyed this technical deep dive and want to see more stuff like it please let us know! Having the chance to share something like this with you all is very special to me. I wouldn’t be in this industry if it wasn’t for so many developers sharing their passions and inspiring me through their work online.

I’ll leave you with one last debug visualization, showing the spatial partitioning used to decide when points are worth subdividing even if they’re not on screen (but one of their descendants might be):

 

View the full article

Finally, don’t forget to check out the Kerbal Space Program 2 - Show and Tell Highlights from February & March, where the KSP 2 team has shared some really neat footage of some of the stuff they’ve been working on recently, like new power generation modules for colonies, colony fuel factories, new engine exhaust effects, and some amusing kerbal skin experiments.

Remember, you can share and download craft and missions on Curse, KerbalX, the KSP Forum and the KSP Steam Workshop.

That’s it for this edition. Be sure to join us on our official forums, and don’t forget to follow us on Twitter, Instagram and Facebook. Stay tuned for more exciting and upcoming news and development updates!

 

Happy launchings!

 

[RealKerbal3x]

Wow, epic!

[Fraktal]

5 minutes ago, UomoCapra said:

we are giving players the ability to rotate docking port collars added to docking ports.

GET. THE. *bleep*. OUT.

There goes the DockRotate mod from my mod list. Awesome! 

[Pthigrivi]

Just now, Fraktal said:

GET. THE. *bleep*. OUT.

There goes the DockRotate mod from my mod list. Awesome! 

I know I feel like 8 years of OCD twitching over docking ports just relaxed out of my shoulders. 

[The Aziz]

Hohohohooomylord

You just saved my OCD

Also

Ground anchor now... Weren't we supposed to be able to anchor things to the ground automatically since 1.11? Maybe I missed that feature and somehow never used it, idk.

 

carefully waiting how many people mention their OCD in next posts

Edited May 20, 2021 by The Aziz

[kspnerd122]

Nice, finally, I can deal with my OCD regarding docking ports

[T1mo98]

This all looks and sounds awesome!

Though, I think you guys missed to post the screenshot of the 1.25m Docking Port

[Minmus Taster]

Rip Dockrotate.

[GuessingEveryDay]

8 minutes ago, Pthigrivi said:

I know I feel like 8 years of OCD twitching over docking ports just relaxed out of my shoulders. 

6 minutes ago, The Aziz said:

You just saved my OCD

5 minutes ago, kspnerd122 said:

Nice, finally, I can deal with my OCD regarding docking ports

You know you guys can try using SMART A.S.S's target rotation, right? It's very help--

Jumps into bunker before Mechjeb debate starts again, and spends rest of days regretting it.

[kspnerd122]

Mechjeb is cheaty, real KSP players play the game legit(no mods that play the game for you)

[Minmus Taster]

Will a docking port with an old texture be able to dock with a new one?

[RealKerbal3x]

Just now, Minmus Taster said:

Will a docking port with an old texture be able to dock with a new one?

Considering how ubiquitous docking ports are on people's craft, they may just directly apply the new textures to the old parts instead of creating new parts and deprecating the old ones.

[Fraktal]

On the other hand, is it just me or does the video indicate docking ports have a very limited rotational range?

[Pthigrivi]

1 minute ago, kspnerd122 said:

Mechjeb is cheaty, real KSP players play the game legit(no mods that play the game for you)

I still use it for aerobrake prediction and a few other niche features. 

[HB Stratos]

Very cool update, it's definitely looking good. But I have a few concerns still

- Will we be able to control the rotation docking ports via action groups? That would be very useful to have. 

- Why the black/yellow striped line on the SR docking port? It makes it so much less versatile to use the port and really doesn't fit the look combined with the more modern looking parts. It also makes the docking port look way smaller than it should. The shielded docking port has a similar issue with it's yellow line, though it's not as bad here.

- How is it looking with bug fixes? Decouplers are still broken and let decoupled things simply freeze in place. Something that has broken many contraptions for me, or forced me to switch to the worse looking radial decouplers. 

- I also fear the ground attachment will lead to a lot of bugs and spazzing out when used. How will this be dealt with?

I'd love to hear some replies on this, thanks!

Edited May 20, 2021 by HB Stratos

[rettter3]

10 minutes ago, Minmus Taster said:

Rip Dockrotate.

Same thought

[Guest]

Looks great, nice job. Seems like this will be a great update for all players

[Hypercore]

12 minutes ago, Minmus Taster said:

Rip Dockrotate.

Our thought are with you

[Rocketology]

KSP 1.12 is Coming in Hawt! Ground anchors for the win!

 

[Poodmund]

Cool stuff, would the part designer of the docking ports be able to confirm or deny whether the collider mesh sizes and docking transform positions have been retained exactly when compared to the current parts?

[Spaceman.Spiff]

39 minutes ago, UomoCapra said:

requested features & quality of life additions

Ah yes.....

Life Quality.

I like the new stuff, but I think the important questions haven't been asked... WHAT'S THE SPECIAL THING?!?

[jshu]

Thanks a lot, especially for the Ground Anchor!

[Le Lynx]

Cool!

[The Aziz]

15 minutes ago, GuessingEveryDay said:

using SMART A.S.S's target rotation,

Well, the less MJ features I have to use to make craft look right, the better.

 

11 minutes ago, Fraktal said:

On the other hand, is it just me or does the video indicate docking ports have a very limited rotational range?

15⁰ sounds like more than enough even if you're docking manually. I'd think of the feature as a limited rotation servo built within the docking port.

One more thing though... The bottom side on Sr docking port still looks very similar to the top, and I know from personal and other's experience that it was a cause of confusion in the past. And there's a high chance it will remain confusing for some. Any chance that it could be slightly edited? I mean it doesn't need a hatch handle and colored ring on the side that is going to be hidden at all times anyway.

[Spaceman.Spiff]

2 minutes ago, The Aziz said:

One more thing though... The bottom side on Sr docking port still looks very similar to the top, and I know from personal and other's experience that it was a cause of confusion in the past. And there's a high chance it will remain confusing for some. Any chance that it could be slightly edited? I mean it doesn't need a hatch handle and colored ring on the side that is going to be hidden at all times anyway.

YES. 

On my first space station I put all the SR docking ports on backwards.