[1.9.x] TUFX - Post Processing

[Remkeau]

Cheers @Shadowmage, I've been mucking around to reliably use KS3P lately, so this is great!
Using forced DX12 for scatterer, EVE and no problems running TUFX (now just need to tweak settings I guess)

No:

 
Yes:

 

Edited March 9, 2020 by Remkeau
Layout

[Shadowmage]

8 minutes ago, Remkeau said:

Using forced DX12 for scatterer, EVE and no problems running TUFX (now just need to tweak settings I guess)

Glad to see the DX12 shaders/etc are actually working.  I included them (along with the OpenGL versions) in case anyone wanted to give it a try...

 

Happy to hear you are enjoying it; feel free to post up any glamour shots or customized profiles if you desire

 

[Shadowmage]

Been 'playing' with something the past week:  porting 'Bruneton's Improved Scattering' ( https://github.com/Scrawk/Brunetons-Improved-Atmospheric-Scattering ), rewriting it in HLSL to be compatible with the PostProcessPackage v2 (used by TUFX), rewriting the C# code to work with he PPPv2, and finally, toying around with KSP to get it working there (not as simple as it sounds).  The source that I was working from was more of a 'proof of concept' than a full-blown functional implementation (it worked but was very much hard-coded for the single included demo scene), so there was quite a bit of hacking to do to get it all working (and a fair amount of learning along the way)... but...

 

Note, it still looks quite 'bad', mostly because I'm still working on hacking all of the usability into the shader -- a ton of depth-buffer related work to do, some aliasing to clean up on the horizons, and need to figure out the math for how much the scatter occludes objects viewed through the atmosphere (the depth-based fog effects).  Also the setup is just slapped in there as far as brightness/exposure, and it is using the stock Earth scale-heights and other values (but on a Kerbin sized atmosphere...).  Quite a bit of the depth-sampling stuff is is already (more-or-less) working in my editor versions of the shader, but these screenshots were taken with a slightly older version of the shader.

Also, this is not going to be a replacement for Scatterer or EVE.  I have no intention of putting the kind of effort into it that it would require, and those mods are perfectly functional already (well, as soon as they are updated to 1.9).  This is intended to be a quick and 'much better than Stock' post-process effect for the atmosphere (possibly on Kerbin only), and also (its main intention) to serve as a 'proof-of-concept' of utilizing the scattering effects from within the Post Process Package pipeline (which is integrated into Unity and optimized as much as it can be).

Edit: Brought in the updated shaders, tweaked a few settings...

Its still not 'right', needs some further tweaking to the actual scatering parameters to rescale a 'earth-like' atmosphere to Kerbin (real science makes that hard to do in a physically-based setup like this... but can likely find something workable).

Getting there...

 

Edited March 12, 2020 by Shadowmage

[jrodriguez]

I have spent most part of the weekend creating a profile for RSS/Earth. This is the result  .(DX 12) Thanks @Shadowmage

Edited March 16, 2020 by jrodriguez
more screenshots

[Shadowmage]

More work over the weekend, still just doing research, playing with things, and learning some new techniques...

(lighter and darker areas are 'higher and lower' in the heightmap;  blue highlighting is from specular lighting, showing bumpmap application; background is random colors based on view-direction...)

(this is the same scene, but rendering the world-space normals)

(same scene again, showing just the generated height-map... which is little more than simplex noise at this point)

This is a 'screen-space bump-mapping' technique (there is no geometry being rendered...); the entire thing exists only in the shader code / parameters fed to the shader.  Bunch of trig to determine where the sphere should be drawn based on the input values for size and location.  Use the world-space position on the surface of the sphere to sample a 3d noise function to generate a seamless height-map (no distortions, no pinching, no stretching, no weird stuff at the poles).  Calculate a tangent-frame for the world-space position on the sphere, and use that to derive a 'sphere-surface tangent-space normal' value from the sampled noise point and its neighboring points.  Transform the tangent-space-normal value back into world-space, and manipulate/adjust the existing analytically derived surface normal accordingly.  Finally, use the combined world-space surface normal to calculate diffuse and specular lighting for the sphere based on the primary light in the scene. 

One of the best parts is that it can all have dynamic LOD applied based on view depth;  surfaces can appear smooth from a distance, with the details manifesting (smoothly, without pop-in) as the zoom level increases, with no maximum zoom level defined.  You want sub-mm resolution of details? Fine.  The noise sampling point-distance actually decreases as the camera nears the surface, enabling per-pixel sampling at all zoom levels, maintaining a very smooth look all the way down to the finest detail levels visible in a KSP camera based on its near-clip distance.

Why would I do such a crazy thing you might ask?  Ocean/water rendering.... specifically, rendering of the ocean surface and the optical effects of waves and surface distortions.  Originally I had intended to not do anything with oceans, but after realizing that it is the stock KSP oceans that cause the issues with HDR, I figured it might be worthwhile to include something quick-and-functional (as HDR can make the rest of the effects so.. much.. better..).

Currently it is using a quick and dirty 'shader based simplex noise' implementation for generation of the height-map, but all of the functionality is in-place to enable use of FFTs or other more realistic water surface calculation methods, merely need to get to a point where it would be practical to implement them.  Furthermore, as it is all just a screen-space effect, it will likely be more efficient than KSPs existing 'mesh based' solutions for specific hardware.

I'm planning on joining the screen-space water-surface effect with a volumetric-water-lighting shader; basically atmospheric scattering, but for water (possibly even just adapting the scattering system to do oceans as well...).  Will handle the optical effects of underwater fog, light-color-extinction / light extinction based on depth and distance the rays travel through the medium.  Should all be very 'physically based' when it is done, but should also be configurable to allow for non-realistic uses (e.g. EVE... why is it purple?).  So far I'm not planning on implementing any complex reflection or refraction setups, nor caustics or anything special in regards to lighting (no volumetric shadows...yet).  Want to get the basic effect setup and working before I try to add in the more complex functions.

 

Yes, I'm also still working on the scattering shader.  It functions, but with caveats and issues I'd like to track down before I release anything.  Need to implement a full config-file based system to specify the bodies on which to use the effect, and the settings for each of those bodies.  Need to do further cleanup and validation of the loading code and the configuration functions, and give the entire thing a good pass over to look for source-code issues in the shaders (was a very hacky port to PPPv2; much stuff commented out, done terribly inefficiently, or simply incorrect and not yet updated).

 

Also still working on the configuration UI in regards to adding the 'spline parameter' editing functionality.  Might still take a while to get this in place, as I've yet to find a workable system that can be done under the Unity IMGUI system.  Likely though I will have this finished for the next major / 'feature' release (excluding any bugfix release that may happen before then).

[jrodriguez]

This is all thanks to TUFX power

 

[Shadowmage]

More fun with rendering post-process rendering; this time...something different (but still a bunch of spheres...).

What is being rendered there is a 'shadow depth' value, from the perspective of the light.  The 'standard' view of the scene can be seen below:

This is actually driven by a secondary camera that renders high-precision floating point depth (from the light's perspective) to a render-texture, which is dynamically positioned, ranged, and configured to keep the 'planet' skybox in its view.  From there, the world-space rendered position is basically raycast into this depth texture, to tell how far the surface is from the nearest object to the light.

The process I've best seen explained here (quite a good read actually): https://medium.com/@shahriyarshahrabi/custom-shadow-mapping-in-unity-c42a81e1bbf8 ,  though I'm doing things quite a bit different than that implementation.

The question again on all of this might be 'why?'  Well, more cool effects, of course.  This one is what is needed for volumetric shadows, part of the volumetric lighting implemented in the scattering shader: https://en.wikipedia.org/wiki/Volumetric_lighting.  Again, I was originally intending to not do any such work, but realized that many of the artifacts currently seen in the scattering implementation are due to lack of shadow depth information being fed into it, so it is illuminating things improperly in some cases.  Can/will also be used for the ocean rendering, to likely very good effect.

Still just playing around at this point, haven't started creating anything 'usable' out of all of this.  Exploring the concepts, developing some code, learning some techniques and learning a ton about Unity rendering pipeline and shaders/graphics in general.  Fun stuff...

 

[Morningrise]

Hi all! First time using this kind of mod and I have a quick newb question! Where do I find exported data or log file used for making new config files? I Don't see it in KSP.txt

Thanks!

David

[Shadowmage]

20 hours ago, Morningrise said:

Hi all! First time using this kind of mod and I have a quick newb question! Where do I find exported data or log file used for making new config files? I Don't see it in KSP.txt

Thanks!

David

You are looking for the KSP.log file, which should be located in the same directory as the KSP executable/binary (at least on Windows).

Then, in the log file, your exported profile should be near the bottom of the log.  Copy the profile config node out, and save it into a new text-file located somewhere in your KSP/GameData directory.  Change the 'name=' line in the config to give it a new and unique name, and then launch KSP.  Your newly created profile should show up in the profile selection list.

[jrodriguez]

Hi all,

This is the current profile I'm using for a realistic Earth view in RSS. I still doing changes because at the end is always a trade-off specially regarding light intensity (Autoexposure/PostExposure are the key values here). This profile is specially tailored for earth-orbit view and ground view. 

However, other celestial bodies like Moon are a bit darker or brighter depending on its "albedo". Also the Earth view from Moon is much more brighter than in reality but as I said before, it is a trade-off.

 

TUFX_PROFILE
{
    name = Default-Flight // Current profile name.  Please make copies of the default profiles and specify new names if you wish to change settings.
    hdr = False
    antialiasing = FastApproximateAntialiasing
    EFFECT
    {
        name = AmbientOcclusion
        Intensity = 4
        NoiseFilterTolerance = -5.38364744
        BlurTolerance = -5.02830172
        UpsampleTolerance = -5.63522005
        ThicknessModifier = 0.00999999978
        Radius = 1
    }
    EFFECT
    {
        name = AutoExposure
        Filtering = 0,82.5999985
        MinLuminance = -3.36037779
        MaxLuminance = -5.7
        KeyValue = 0.02
        EyeAdaption = Progressive
    }
    EFFECT
    {
        name = Bloom
        Intensity = 0.200000003
        Threshold = 1.5
        SoftKnee = 0.709999979
        DirtIntensity = 5
    }
    EFFECT
    {
        name = ColorGrading
        GradingMode = HighDefinitionRange
        Tonemapper = ACES
        ToneCurveToeStrength = 0
        Temperature = 6
        HueShift = -6
        Saturation = 2.8499999
        PostExposure = 4
        Contrast = 6
        Gain = 1,1,1,-0.5
    }
    EFFECT
    {
        name = ChromaticAberration
        Intensity = 0.0299999993
        SpectralLut = KS3P/Textures/SpectralLut_RedBlue
    }
}

@Shadowmage I'm using a spectralLut from KS3P but I'm not completely sure if this feature is currently supported. I can't see on the UI if the defined spectrallut is being used (I have created a Fork and I'll investigate it)

[Shadowmage]

8 hours ago, jrodriguez said:

I'm using a spectralLut from KS3P but I'm not completely sure if this feature is currently supported. I can't see on the UI if the defined spectrallut is being used (I have created a Fork and I'll investigate it)

I believe the config you posted should be valid/usable, but the texture-use side of the effects was mostly untested; as I was unsure what they should actually do, I had no way to know if it was functioning correctly.

If you want to make the texture available for selection from the in-game UI, you would need to define a config node for it, such as can be seen here for the bloom lens-dirt textures:  https://github.com/shadowmage45/TUFX/blob/master/GameData/TUFX/Textures/BuiltinTextures.cfg

Please let me know what/if anything you find in your investigations; will be glad to fix up anything that might need some attention code-wise.

[clusta]

@Shadowmage (At last!) Someone implements v2 shaders! Honestly, Im implements it in KSP too, but not released yet I tried to support KS3P, but later decide to make mod from scratch. No details, but there is not about simply apply v2 PP Unity package. So, maybe sometime this will be a challenge?

[Fringified]

Has anyone noticed any issues with Ambient Occlusion? It's been the one thing bothering me and I was curious if anyone is experiencing the same issues. I'm getting these weird banding effects the closer you get to an object. It's subtle but you can also notice it on the ground as well.

I've tried tweaking all the available options but none seem to be effecting it.

Looks pretty fine here.

You can start to see it near the cockpit here, and the fuel tank and forward wing section.

Another shot from the rear. In a second I'll switch to the HDR-Flight profile. This is the default flight profile.

And this is with the HDR-Flight profile, with the AO more intense. You can really notice it here.

 

I hope this doesn't come off as nit-picky. This mod is fantastic and served as a replacement of KS3P for me after I recently updated from 1.7.3 to 1.9.1. This is literally the only thing bugging me.

[Electrocutor]

Over at the Unity forums, they chalk the banding up to the near and far clip planes on the camera:

Quote

This looks like banding artifact caused by near/far plane setting in the camera.

Try setting near plane further from camera and far plane closer. This should reduce the banding. Also when you turn on the setting "GBuffer Depth&Normals", this might also help.

Shadow might need to allow these setting tweaks via config.

Otherwise, perhaps setup the near/far clip to be dependent on zoom level?

Edited April 6, 2020 by Electrocutor

[badwolf90]

I've been playing around with motion blur and captured a really cool shot :

https://imgur.com/a/qmeuqbA

Also noticed that wheels are being blurred :

[Electrocutor]

@Shadowmage It's been mentioned to me that the most likely reason for banding is if the color precision is off, for example blending the depth (16-bits per pixel) into a normal texture (8 bits per pixel).

[Arco123]

NVM

Edited April 14, 2020 by Arco123

[Virtualgenius]

@Shadowmage this looks totally awesome what great scenery shots cant wait for everything else to catch up with it Scatterer and Eve 

Edited April 16, 2020 by Virtualgenius

[Zorg]

@Shadowmage Been using TUFX for a little while and just wanted to drop in to say how impressed I've been. TUFX has lived up to all of the promise KS3P teased at. 

If I might ask for small quality of life feature, a configurable hotkey to bring up the GUI might be a nice option to have, would enable much quicker profile switching on the fly in the midst of flight. No big deal but worth considering?

Signing off with some screenshots featuring WIP profiles I've been using in KSP 1.8.1

 

 

 

 

 

Edited April 17, 2020 by Zorg

[CDSlice]

@Zorg those are amazing! Would you mind sharing your configs? Even if they are rough they would make a great starting point for people to base their own configs on.

[Zorg]

17 minutes ago, CDSlice said:

@Zorg those are amazing! Would you mind sharing your configs? Even if they are rough they would make a great starting point for people to base their own configs on.

I've posted them here now, Imo the main colour profile can be a bit dark on the night side (pitch black really), you probably need to tweak your ambient light and or planetshine settings until you can just about see enough to click on things. I'm not using eye adaptation on the main colour profile as I cant seem to consistently create the look I want. Its actually quite basic, just AA, a small amount of bloom and some tone mapping stuff.

I will be working on some vintage colour film inspired profiles at some point and will post it up there when I do.

 

Edited April 17, 2020 by Zorg

[blackrack]

On 3/12/2020 at 2:06 AM, Shadowmage said:

Been 'playing' with something the past week:  porting 'Bruneton's Improved Scattering' ( https://github.com/Scrawk/Brunetons-Improved-Atmospheric-Scattering ), rewriting it in HLSL to be compatible with the PostProcessPackage v2 (used by TUFX), rewriting the C# code to work with he PPPv2, and finally, toying around with KSP to get it working there (not as simple as it sounds).  The source that I was working from was more of a 'proof of concept' than a full-blown functional implementation (it worked but was very much hard-coded for the single included demo scene), so there was quite a bit of hacking to do to get it all working (and a fair amount of learning along the way)... but...

Note, it still looks quite 'bad', mostly because I'm still working on hacking all of the usability into the shader -- a ton of depth-buffer related work to do, some aliasing to clean up on the horizons, and need to figure out the math for how much the scatter occludes objects viewed through the atmosphere (the depth-based fog effects).  Also the setup is just slapped in there as far as brightness/exposure, and it is using the stock Earth scale-heights and other values (but on a Kerbin sized atmosphere...).  Quite a bit of the depth-sampling stuff is is already (more-or-less) working in my editor versions of the shader, but these screenshots were taken with a slightly older version of the shader.

Also, this is not going to be a replacement for Scatterer or EVE.  I have no intention of putting the kind of effort into it that it would require, and those mods are perfectly functional already (well, as soon as they are updated to 1.9).  This is intended to be a quick and 'much better than Stock' post-process effect for the atmosphere (possibly on Kerbin only), and also (its main intention) to serve as a 'proof-of-concept' of utilizing the scattering effects from within the Post Process Package pipeline (which is integrated into Unity and optimized as much as it can be).

Edit: Brought in the updated shaders, tweaked a few settings...

s still not 'right', needs some further tweaking to the actual scatering parameters to rescale a 'earth-like' atmosphere to Kerbin (real science makes that hard to do in a physically-based setup like this... but can likely find something workable).

Getting there...

I personally completely gave up on using a depth buffer for scattering effects and went with the nuclear option instead a few versions ago (re-render all geometry with a scattering shader using a projector) for a few reasons:

1) KSP is forward rendered so MSAA is very cheap and everyone uses it. The unity provided depth buffers aren't multisampled so the edges of objects never match the scattering for them and you get annoying aliasing around objects and horizon. Also, multisampling or supersampling a depth buffer doesn't make any sense: you get wrong depths which are an average, however calculating scattering and extinction for that depth won't give you the same average color as the average color obtained from scattering for all the samples, so edges always look weird, if this makes any sense.

However you could get around this by using only TAA or FXAA, like a deferred renderer.

2) Precision issues with the depth buffer: No matter what, if the farClipPlane is 750000 and the nearClipPlane is 0.21, reconstructing position from depth can be somewhat inaccurate, and requires all kinds of hacks and tricks to work around and hide artifacts and all kinds of crap.

 

If you find some solutions for these issues however I'd be interested in how you solve them.

Also are you generating the precomputed scattering textures ingame or just loading them?

Back then for scatterer I had to be compatible with directx9 which had no support for 3D textures. Knowing that Bruneton's scattering uses a 4D texture, stored in a 3D texture with interpolation done manually on the 4th dimension, I had to store the 4D texture in a 2D texture and do the interpolation manually for the remaining 2 dimensions... It gave me headaches, luckily code from Scrawk saved me.

Also, what you call "the math for how much the scatter occludes objects viewed through the atmosphere" is extinction, it should be computed by the same functions that compute the scattering.

Edited April 19, 2020 by blackrack

[Shadowmage]

15 hours ago, blackrack said:

Also are you generating the precomputed scattering textures ingame or just loading them?

Generating them in-game / at runtime.  I took the entire Improved Scatterer project, and shoehorned it into the Unity Post Process stack, mostly unaltered.  Still mostly an academic project, to learn the ins and outs of the scattering system, volumetric effects, and how to work with the post-process stack.

15 hours ago, blackrack said:

I personally completely gave up on using a depth buffer for scattering effects and went with the nuclear option instead a few versions ago (re-render all geometry with a scattering shader using a projector) for a few reasons:

Yeah, the more I play with the depth buffer, the more I run into these limitations.  Trying to do planetary scale volumetric shadows, with anything less than a 8k shadow map, was full of terrible artifacts.

The basic scattering effect was workable from depth buffer alone, but getting all of the rest of the pieces working was not going well.

 

[blackrack]

1 hour ago, Shadowmage said:

Yeah, the more I play with the depth buffer, the more I run into these limitations.  Trying to do planetary scale volumetric shadows, with anything less than a 8k shadow map, was full of terrible artifacts.

Do you have any screenshots? I'm curious what volumetric shadows derived from shadowMaps look like in KSP, I'm also thinking about 8k shadow maps and some careful tuning to cover 50km+ shadows.

[Electrocutor]

Would there be a way to arbitrarily set the depth buffer to a much nearer far plane, while still only using a single camera? Or have it prioritize precision nearby? I also wonder if allowDynamicResolution would help.

I see that DepthTextureMode.MotionVectors holds 4 times more data than the other modes, but I'm not sure the resultant depth texture would be useful to what needs it.