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

Quote from Dean Hall:

WIP terrain material work from Linx

So Linx has been hard at work. These images are from our internal discord and I just couldn't wait to show everyone, so here's some screenshots and a little bit of detail from Linx. Hope they are okay with me posting this! Please remember it is very work in progress:

*Biplanar textures, correct normal mapping, and support for biome materials each with their own surface and cliff texture! The Moon isn't the best example to show off a bunch of biomes - I've got a very subtle setup. The main surface, craters, and maria are different biomes with very subtle differences in the terrain materials but they all share the same cliff texture. The cliff texture itself is probably slightly more dramatic than the moon actually has but is good for showing it off. All the biomes are based off the same dusty texture, with the craters having more rocks and the maria being smoother. Placeholders at best for now. [...] There are no detail heightmaps yet until we're able to compute the deformed mesh normals *

Rocketwerkz' KSA townhall on discord.

ShadowZone "5 things to expect"

ShadowZone "Early gameplay analysis"

ShadowZones interview with Rocketwerkz' CEO Dean Hall

Kitten Space Agency (currently referred to as a working title by Rocketwerkz, we'll see if it sticks) is intended as a spiritual successor to Kerbal Space Program.

Rocketwerkz is a studio from New Zealand and were among the ones originally placing their bids with Take2 Interactive for developing a Kerbal Space Program successor, but after they lost the bid, any work was shelved.
However, after Take2 severely botched the sequel, Rocketwerkz revisited some of the early work, as well as its engine and framework, and decided to develop a spiritual successor instead.

Some of the developers from Kerbal Space Program as well as its massive modding community are onboard. Off the top of my head, this includes:

• HarvesteR - The original creator of KSP
• Blackrack - Known for various visual enhancement mods to KSP