neidu3

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

Requirements:

• Domain registration (duh)
• Privacy.
• DNS included.
• Preferably based in the EU, but it's not a hard requirement

And are there any you would support if you had just that little bit of extra disposable income?

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.