neidu3

...which allows for some nice plots when you're at semi-synchronous orbits. Can't wait to position site survey (spy) satellites this way:

Bright green is current orbit. Darker and more faded greens for subsequent orbits.

Pretty fresh off the press, judging from the nav computer and ground tracking window.

From Gravhoek on Discord:

Here's a quick look at my most recent pass on the autopilot control panel. I'm already planning on making a few more changes in the next few days (specifically around burn execution), but you can see what's been done so far. This will also get a pass from Dean and his fancy new UI.

A. K. A. Which song do you hate the most?

From Linx on Discord:

A quick look at the detail heightmaps in action and how fast it is to make edits to the terrain. It's pretty satisfying to see the textures update to reflect the new context of the terrain. I spent longer than I should have playing around with this!

Detail heightmaps are per-biome so planets won't have the same one everywhere. Due to their tiling/repeating nature they won't be used in places where that becomes obvious; I'm thinking they'll be applied to slopes or cliffs to add some extra detail to stop them from looking lumpy. I'm also going to be looking into procedural elements! Procedural noise is great for adding non-repeating detail that also isn't limited by the resolution of a texture, but requires a lot of care so that different locations don't look "samey". The planets will still be mostly driven by heightmaps, but closer to the surface where the heightmap resolution becomes too low is where procedural elements shine - KSP uses this. Not sure how far down that rabbit hole we'll go as I've only recently started looking into it, but it's something I'm interested in.

I leave you with a fun fact: Minmus in KSP is entirely procedural. If you change the seed using a mod you get an entirely new version of the minty moon 😉

.

Some relatives and I are undergoing the formalia regarding selling the house and property my grandfather left us when he passed last year.

While filling out the forms electronically I noticed that the small field labelled "Protected due to culturally significant site" was automatically ticked.

So I just looked it up, and as expected it was in regards to the old cemetery right next to the property. For as long as I can remember we always referred to the area as "The old cemetary."

I allways thought it was like 200 years old at most. Nope, turns out that it's almost 600 years old on paper - The first written reference to the site is from 1432, and it is therefore most likely older. And a small piece of it overlaps with the property from my grandfather.

If it wasn't for the fact that we've all agreed to sell our share to my aunt I would've asked my GF if she's interested in becoming creepy crypt keepers when we retire.

From Gravhoek on Discord:

For anyone interested in how RCS control works internally, I thought I would post a couple shots of its "brain" during a maneuver.

If you have some familiarity with how automatic controls work you've probably heard of PID - that's not how this controller works. The problem with PID is that it doesn't handle actuators (RCS jets, in our case) that have a "minimum impulse" very well. That is, you can't fire an RCS thruster for an infinitely small amount of time. In practice, this means every correction you make is always at least a slight overcorrection, which means you're going to have to accept a bit of "wobble" around your target.

To handle this without constantly firing back and forth and wasting fuel, you need what's called a "dead band" where you just coast and allow your pointing angle to drift away from your target angle a little bit. Then, when you get too far away, you make a small correction and drift back the other way. When you end up in this pulse-drift-pulse cycle around your target and the pulses are minimum pulses (meaning the smallest possible RCS firing time), this is called a "limit cycle", which we will see in this graph.

The graphs here display something called "phase space", which is a general term in control theory. For our purposes, it is a graph of two errors - error being the distance from your target state to your current state. The two errors we care about for each axis are angular error (the X axis) and angular rate error (the Y axis). Basically, how far you are from the target and how fast you are going relative to the target.

The big red dot on the graph is your current location in phase space. The lines on the graph are called switching lines - hence why this is called a "switching line controller". If you are below the lines, it means you need to increase your angular rate. If you are above the lines, it means you need to decrease your angular rate. Between the lines is the "dead band", where all thrusters are off. You can see the lines converge towards zero rate and zero angle at the center, which is why this controller guides the spacecraft to its pointing target.

The three images here show a complete maneuver.

1. The initial angle offset where the red dots are far outside the lines.
2. Mid maneuver where the red dots are inside the lines but we are rotating around towards the target. This is the coast phase where we are spinning but there are no thrusters firing.
3. The "on target" phase where errors are close to zero.

Once you get close to the origin (zero rate, zero angle), the shape of the lines change into the squarish structure you can see on the zoomed picture. Here you can see several things more clearly:

1. The yellow lines are the switching lines described before.
2. The green line is the target line - when you are outside the switching line, you try and fire thrusters to hit this target line.
3. The gray box shows the expected "limit cycle" - the path you expect to take if the spacecraft is doing the least amount of work possible to keep the target within the dead band.

In the video you can see what the limit cycle looks like in practice. Note that the thruster firings in pitch and yaw are slightly coupled (e.g. firing in yaw causes a small change to pitch rate). This is because the thruster pods on the Apollo CSM are slightly rotated around the vehicle, so e.g. the "yaw" thrusters are actually "mostly yaw and a little bit of pitch" thrusters.

Note: The referenced video doesn't want to embed. You can see it here.

From Gravhoek on Discord:

Celebrating finally getting my RCS controller committed! Here is a "solar marathon" while holding a nose forward attitude using RCS.

Posted by Dean Hall this morning.

.

.

.

.

From Blackrack on discord:

Atmosphere rendering improvements: Ozone and multiple scattering

As you've probably noticed in the last few videos, ozone is now supported. Unlike other atmospheric components, ozone only absorbs light (mainly green) instead of scattering it. This enhances the look of sunsets, as without ozone the atmosphere takes on a greenish hue.

The first screenshot compares a sunset without ozone on the left and with ozone on the right. The second screenshot shows the ozone layer from space which can be spotted as a distinct blue band, similar to this photo from the ISS.

Multiple scattering is also now implemented and can be seen on the third screenshot. It allows light to bounce several times in the atmosphere instead of just once. This can be subtle but helps with the realism of the atmosphere. It also works well with godrays, where objects block only the first light bounce, but the atmosphere can continue to receive light from the sky itself, softening the look of atmospheric shadows. The last screenshot shows a mountain casting a shadow on the atmosphere, with both ozone and multiple scattering, similar to this photo

Additional pictures:

.
. .