Kitten Space Agency

From Gravhoek on Discord:

While testing...other things, I captured this footage. This is 24 hours hanging over Hawaii (note that I turned clouds off so you can see the terrain better). I actually got into this orbit manually - even though it's obvious that geosynchronous orbits would work in KSA, it's still cool to see!

It's mostly stuff I've already covered in my posts, but I'd say it's still worth a watch because:

• He's a generally good source of info, and a lot of t better at presenting objective facts than I ever will be.
• Interest in his channel leads to interest in KSA, meaning (hopefully) more contributions to the game when it's time for that.
• There's an interesting nugget of information about Nate Simpson
  Tap for spoiler

  of KSP2-fame (or infamy) (redacted due to coummunity rules)
  ...and what he's been up to lately in there. I for one hope he succeeds, as I feel he got severely shafted by Take2.

From Gravhoek via discord:

Aerobraking passes at 1 week/second time warp. There is no trickery here - we are simulating all of the parts outside of the atmosphere with Kepler, and all of the parts inside the atmosphere with full physics.

We'll see if it remains as efficient and flawless once they've implemented a more robust and realistic drag model instead of the current spherical placeholder.

Multimonitor users rejoice!

From Dean Hall a.k.a. Rocket on Discord:

you can now pop out instruments onto any window or screen!

We have your plan figured out buddy, you are going to fill a spaceship with empty boxes and objects placed precariously close to edges, lure all of earth's cats on and then send us to mars so dogs can rule earth.

Good luck herding us into the spaceship!

Gravhoek on discord:

I added a simple spherical drag model to our humble CSM. Here we are falling through Blackracks beautiful clouds at terminal velocity.

From Gravhoek on Discord:

Here are all the camera modes that are currently in the game. Each of them has their use, some more niche than others!

For those of you on mobile, the camera mode names can be a bit hard to see, but they are as follows, in order of appearance:

• Parent
• Stars
• Chase
• Surface
• Orbit
• (switched to map view, which seems to be a

Source: gitbot

gravhoek-rw

+ Added the ability for vehicles to collide with and rest on planetary surfaces. This is a very simple version to start which treats the vehicle as an analytic sphere and only collides directly in the radial direction. It also does not take the surface normal into account at the moment.
+ Added a symplectic Euler integrator which we use to resolve collision along with a scheme of sequential impulses.
* Major rework to vehicle state and update logic. We can now choose multiple different update methods within a single frame - for example, taking a Kepler step to the edge of the atmosphere, integrating with velocity Verlet to the surface, and resolving and impact with symplectic Euler.
* Added a minimum target framerate to prevent the FPS "death spiral" when there is too much work to get done in a single frame, so the target frame time increases exponentially each time. We will now scale back the time compression rate to try and fit within a reasonable frame rate.
+ Added a new Simulation tab to the game settings for various physics parameters.
* Adjusted celestial creation to be a full preorder traversal, meaning each celestial is fully baked before its children are instantiated.
* Lowered the minimum camera altitude to 0.5 meters.
+ Added some float3 extension methods and renamed DoubleVectorEx to Double3Ex.
+ Added a physics debug window.
* Changed the patched conics parent impact detector to use a direct calculation rather than a bisect search.
* Fixed attitude snapping using the wrong coordinate frame rates.
+ Fixed debug thruster arrows being drawn in the wrong location.
+ Added LC-39A to Earth landmarks.

From Dean Hall on Discord:

You can see the SDF font gauge is working great and there is almost no aliasing whether the gauge is large or small. Might be hard to wrap your head around, but in drawing these gauges no mesh or texture* is involved at all. (technically, a texture is used for the SDF font but not in a traditional texture sense). This has a lot of benefits I covered earlier. You can see animated mechanical rollers for representing numbers in this demonstration as well. These gauges are generated entirely from runtime "mod data" meaning the way we make them is the same way modders do. The shader itself is able to access a global shader binding that is very efficient when it comes to transfering data. Individual shaders/gauges don't need special bindings for data, they have access to all the data. Allowing gauges of incredible complexity, for only the per-pixel cost of the shader itself.

From Dean Hall on Discord:

This shows the early progress on multiwindow rendering, showing me "undock" the settings menu seamlessly. When the settings window is dragged outside of the main viewport, a new application window gets created. This has tremendous use for many situations, especially so when rendering different cameras such as when doing interplanetary transfers. Hopefully this video gives a good indication to people the power of this functionality.

From Dean Hall on discord:

A lot of progress has been made improving a lot of our rendering process for many things, and terrain is one of them. This video shows off progress that has been made, with a great demostration of the seamlessness we now have with spherical billboarding. It is important to remember this video is taken live, realtime, from within the simulation at realistic scales (although the height of lunar features is exagerated for testing).

This video on discord is at 30FPS and and HD only, for a 60FPS and full HD download at: https://drive.google.com/file/d/1bb6F98k1nTESsR0I3YJJDuRwZWC-q9E8/view?usp=drive_link

(content creators welcome to use as always. attribution is not required)

HD version mirrored here

From Dean Hall, playing around with navball config:

This new system allows you to write fragment shaders to "draw" widgets on the screen. All you need to do is write it in XML:

        <Gauge>
            <Component Id="Navball">
                <AnchorUv X="0" Y="1" />
                <PivotUv X="0.5" Y="0.5" />
                <SizePixels X="256" Y="256" />
                <OffsetPixels X="240" Y="-200" />
                <Rotation Degrees="0" />
            </Component>
            <Component Id="TBar">
                <AnchorUv X="0" Y="1" />
                <PivotUv X="0.5" Y="0.5" />
                <SizePixels X="48" Y="48" />
                <OffsetPixels X="240" Y="-200" />
                <!--<Rotation Degrees="45" />--> <!-- would need to use GaugeRotVert to use this -->
            </Component>
        </Gauge>

and these reference defined "GaugeComponents" can get reused:

<Assets>
    <GaugeComponent Id="Navball">
        <Vertex Id="GaugeVert"/>
        <Fragment Path="Shaders/Navball.frag"/>
        <Gauge Id="Fragment"/>
    </GaugeComponent>
    <GaugeComponent Id="TBar">
        <Vertex Id="GaugeVert"/>
        <Fragment Path="Shaders/GaugeTBar.frag"/>
    </GaugeComponent>
</Assets>

which this means is you can write fragment shaders (as an option) to make UI elements. THis is good, but also a little dangerous. If they are small - they are really chheap. but the bigger they get, the more expensive they are
In thiis screenshot i've "unlocked" them so you can see the borders

with this unlocked, I can customize it live, which helps me choose the values to put in the XML

you can resize manually, but in that slider is useful for more precise changes around the pixel etc...

Adjustments seem really fast and simple, both sensible tweaks, and not so sensible ones:

Keep in mind that this is an extremely early state of the game as it's pre-alpha. It's more akin to a tech demo at this stage.

From Dean Hall:

So I've been working on moving away from always using meshes and textures for things like navballs, and doing it procedurally - in this case in a fragment shader alone. Why do this? Well, that's actually a good question. Not one I have a great answer to. Primarily, it started (like much in this project) because I personally don't like the way games look today. Everything is all washed out the heck, its all like someone has spread petroleum jelly over the screen (shakes fist at Tim Sweeney angrily). Bizarely, my time making a lot of complex avionics for my Stormworks vehicles also factored in this.

"What if", I reasoned, "we could make it completely in the fragment"? Not only will it scale really well to any resolution - the nav ball will never have texture "pinching" at the poles, and modders could very easily replace any widget whenver they want with extreme ease. An added bonus you can see in this video, I can move the widget around very easily. To be fair, this would be true (to an extent) for a mesh + texture combo - but you can see it starts to look really great even when I scale it up. This has actually been a good example for me of the paradigm shift we face using BRUTAL. A lot of things get approached from first principles, which means you start asking all kinds of really weird questions and you end up asking what should i do?.

So whats the catch? Well, another really good question. I'm not a graphics programmer, but I'm tempted to say that this procedural shader willl always be less performant than doing it with a mesh + texture combo. However, whether you will notice the performance hit remains to be seen. This is because the entirety of drawing the procedural navball is drawn in the "fragment" shader, with essentially nothing at all from the CPU. No texture, no mesh (well, I do tell the GPU there is a quad - but it doesn't exist, it is just used to make sure the fragment gets called). This has all been quite a ramble.

If I do end up continuing down this path successfully, I can make a lot of widgets like this, which can then be used for IVA gauges and the like, and then rendered on a separate framerate.

From Dean Hall, a.k.a. Rocket:

ChrisH has also been cooking! This is a very WIP image showing this work off . It is still very WIP and chris has a lot of changes coming, this commit was moslty made so he could avoid merge hell going forward.

What does this mean?

Well pretty simply it means we can have multiple application windows open, on different screens and such. This is helpful if you want to have a window on one screen that shows, say, the moon, and then your vessel on another. It is also really useful if you want to make your own peripherals for the game - Flight Sim uses this a lot with aftermarket MFDs and other devices.

More to follow with this!

From Linx:

Here's my current work on terrain tessellation and displacement - this is what makes the planet surfaces look 3D up close and gives them that bit of extra detail. Right now the texture scale is too big so each rock here is far larger than they would be in real life, but that's because the terrain is still being worked on. This should give you an idea as to what we're working towards!

Given that the Moon is grey, I fully expect Discord to crunch all the details out of my videos so we'll see how that goes. I also have VSYNC on - the FPS is a bit higher than displayed and there are still many avenues for optimization to explore. Still very early on and a work-in-progress. Any vertex shimmering isn't anything to worry about, just a result of things being WIP :)

Looks like the building mechanic is in the works, weee

From his discord post:

Thrusters in space

Cold gas, atmospheric

Cold gas, vacuum

Here is my current progress on RCS thrusters using the previously shown volumetric rendering approach The first video shows hot gas thrusters in a vacuum, these were modeled after real references and look quite different from how they're usually rendered in games The next two videos show a starship-style cold gas thruster, first in-atmo and then in a vacuum

Thanks to Stefan for providing the references

By dev gravhoek:

Here I added a simple "map view" button to the game to reduce the tedium of maneuver planning. Since everything is seamless in KSA, this is really just warping between two states of camera zoom!

From the git changelog:

• Switched from mailbox to fifo presentation mode which fixes vsync on Windows.

• Added a toggle between a new "map" mode and local mode using the M key. This "map" mode just zooms out to the currently-followed vehicle's parent for now.

Here's a little demonstration of the Dzhanibekov effect using our rotation-under-time-warp physics. In this case, we are using full Newtonian physics to do the rotation but running the analytic solver in parallel to compare the solutions. The long dim RGB arrows are full physics, the short bright RGB arrows are the analytic solver. Watch the blue Z axis ("down" to the pilots) flip between two directions: towards and away from the angular momentum vector (in yellow).