The White Guardian

THE LEGEND HAS RETURNED!!!

Strange... I'll look into this behaviour.

You can try to run it, but I'm not officially supporting 1.2.2 It uses Unity Engine 5.4.0, and Squad moved over to Unity 5.4 with 1.2.2 so on paper it MIGHT work. However, I compiled KS3P against 1.3, so it's a chance. You can always, as a last resort, try downloading the source code and compiling it yourself with Visual Studio.

*coughing fit* Ssssh! Jeb already theorizes about the possibility of strawberry pudding oceans, don't give him ideas!

Adding that as a built-in feature in the next release. (Clarification: I'm adding an entry to the bloom node to disable the lens dirt)

Like I said, I'll look into this relation, they should not be tied together. More specifically I'll look into making bloom work without relying too much on lens dirt.

I presume it's a nasty side-effect of my KSP install currently being dedicated to the development of my mod Evolution, which also adjusts the light and ambient light settings. The settings look quite alright on my end, but it uses a different star, so that's where the problem likely occurred. Adjusting the settings for the default KSP install is also on the to-do list for the next version, along with bugfixing, fixing the vector2-parser, and making KS3P search through the GameData folder for config files.

Marked to be fixed in the next version. Thank you! There's your answer - my current KSP install is pretty messed up. There's not much to take beauty pics of right now, sadly... I'll look into the relation between dirt and bloom to make this behaviour a bit more streamlined.

The map view is part of the 'flight' scene, so currently any effect made for the flight scene SHOULD appear in the map view... I can, however, try to hook up the Flight scene MonoBehaviour script to KSP's Event system and feed a different PP profile to the main camera depending on whether Map View was entered or not... I'll mark it down for the next update. Shouldn't be too hard. (In fact I'm already mentally writing a prototype code) 100% compatible. All mods, yes. Even other mods that add stuff to the rendering pipeline should work in theory.

(I didn't even know ReShade was a thing) The advantage is that it's built for KSP / Unity and therefore more optimized. ReShade seems to be something external. The lens dirt seems to amplify the bloom effect, because it reacts so heavily to the bloom. I'll look into this. I have absolutely no idea what could be causing this. You're in the tracking station, which is bugged currently, so you're actually not seeing post-processing effects there. I therefore doubt it is related to KS3P - can you confirm that removing KS3P fixes the issue? It is, in fact, using the post-processing stack as a base. Making a config parser and making the whole PP system script-related was a pain in the rear though. The Unity PP stack was designed to be set up in-editor. The license allows it provided that proper credit is given (credit Unity for the PP effects and credit me for making them work in KSP through a config-based system) The problem is that the KS3P dll does not work outside of its own root folder. Therefore bundling it is not a good idea. It's probably better to treat it like EVE and Scatterer and make a custom config for it, for automatic compatibility should KS3P be detected.

Noted for the next update. AFAIK not entering a dirt texture would cause the dirt effect to disable, but maybe that's Unity Editor only. I'll write a fix for it so it doesn't disable the entire effect.

Hey all, brief moment online before I call it a day. First order of business: disabling effects. ( @Kerbital ) The configuration for the post-processing is found in KSPDirectory/GameData/KS3P/Config.cfg In there, you'll find a list of 'Config nodes', each of them named 'Post_Processing'. Inside them is a value labeled 'Scene'. This shows that scene that setup is for. Each scene contains a bunch of sub-nodes, the name of each sub node identifies what effect it is for. For example: Post_Processing { Scene = MainMenu Vignette { //Stuff here } } The above code would add a vignette to the main menu. Mind you, you can only have one profile per scene. If multiple profiles per scene are detected, only the first one will be applied. To disable an effect entirely, remove its sub-node. When loading the configuration, KS3P checks whether or not the node of a specific effect exists. If not, that effect is disabled. The effect is also disabled if a parsing error occurs when loading that particular effect. So, to remove chromatic abberation and the vignette, delete their sub-nodes from each scene you don't want them in. As for the lens dirt, that's actually a part of the 'Bloom' effect. To remove it, simply comment out the entry 'Dirt_Tex' for each scene where you don't want it. (Ergo, change it from 'Dirt_Tex' to '//Dirt_Tex'). This will internally yield a value of 'null', which KS3P will take as 'we don't want lens dirt effects. While on the subject of the dirt texture, the value directly below Dirt_Tex, Dirt_Intensity, controls how 'visible' the dirty lens effect is. You can also set this to zero to disable the effect. Next, compatibility. @kjack1111, KS3P has absolutely nothing to do with the planetary system. It works by inserting a few things into the rendering pipeline. Ergo, when the computer produces a 'frame' (on average, computers do this 60 times per second, hence the term 60 FPS (Frames Per Second), KS3P adds a bunch of effects on top. This means that it is 100% compatible with any planet mod, although fine-tuning it may be necessary in some extreme cases. So, feel free to use it with any mod. Then module manager. @Galileo currently KS3P does not support Module-Manager patching, but worry not. I've added that feature to my local, half-finished copy of the upgraded INSTANTIATOR, and I can add it to KS3P too. I'll just have to look up how I did it again. Currently, when loading the configuration, KS3P grabs a config file of which the location is set in stone, and processes that particular config file for the settings. What I did with INSTANTIATOR (huge thanks to @Thomas P. there) was search through the entire GameData folder for INSTANTIATOR config nodes. I should be able to add this feature to KS3P in a matter of days. (By that I mean that I aim to release a hotfix with this feature tomorrow) As for why I don't have any KSP screenshots up there ( @JadeOfMaar @Horman @DeltaDizzy @AndrewDrawsPrettyPictures ), let me share how the idea behind KS3P came to be, then it'll make sense. You see, I've wanted to add post-processing to KSP for a while now, but I was under the assumption that Unity 5.4.0 (the version KSP uses) was too old for the post-processing shaders. Therefore I had been waiting for the 1.4 update, with the transition to Unity 2017, to make KS3P a reality. Imagine my surprise when I imported the shaders into a 5.4.0 project and found out that most of the shades worked like a charm. That was three days ago. After that I put pedal to the metal and worked on KS3P non-stop. The problem is, I had been using my KSP install to work on my mod Evolution. I couldn't really make in-game screenshots because the planetary system is currently uprooted on my end... I'll make a couple of screenshots with @Galileo's legendary SVE pack installed tomorrow.

That's odd... I'll work some magic. @DeltaDizzy can you see them now?

Allow me to share a little... something

KERBAL SPACE PROGRAM POST PROCESSING MOD Introducing KS3P (KSP Post Processing -> KSPPP -> KS3P), a mod that aims to bring post-processing effects to Kerbal Space Program. Ever wondered 'how come Unreal Engine games always look so smooth compared to Unity Engine? Well, that's the result of post-processing. See an example below: Here's another demonstration from my own computer. Without post-processing: With post-processing: Screenshots They say an image speaks a thousand words. Thanks to KS3P, they may even speak more than that. Here are a couple of side-by-side comparisons. Features - Make KSP look better than ever, with post-processing effects! - Low CPU and GPU cost! - Works with and alongside all your favorite mods! (Including CameraTools!) But it gets better... - KS3P is fully configurable, meaning that every post-processing effect can be fine-tuned. Modders can even set up effect configurations to be scene-specific - KS3P has several features to play with: - Anti-Aliasing (FXAA or TAA) - Ambient Occlusion (Note: does not work right in Unity 5.4.0, but should work like a charm with KSP 1.4) - Screen Space Reflection - Depth of field - Motion blur - Eye adaptation - Bloom & lens dirt - Color grading - Tonemapping (Make the colors pop by harnessing the ACES Filmic and the Neutral tonemappers) - User Lut - Chromatic abberation - Procedural grain - Vignette - Dithering DOWNLOAD Mod: SpaceDock [V6.1 for KSP 1.7.X] Source code: GitHub Documentation: https://docs.unity3d.com/Packages/com.unity.postprocessing@2.1/manual/index.html In-Game editor: Open-close with Left-Alt + 3. Documentation on the way.

I compiled the new ring shader into the asset bundles used by Kopernicus. Now all left to do is downloading a non-compiled copy of Kopernicus from GitHub and updating the ring spawner and ring loader codes to account for the new values. The edited shader has been tested in Unity. It looks a bit strange and color-less, but then again it's not designed to be used standalone.

I think I've merged the shaders. Have yet to compile everything to try it out though. Because I am by far not a shader expert, I'll summarize the changes I made to a local copy, therefore if anyone spots an error, please let me know. Firstly, I added a few lines to the start, after '#define M_PI' uniform sampler2D _DustLarge; //The large dust texture uniform sampler2D _DustSmall; //The small dust texture uniform sampler2D _RingDetail; //The ring detail texture uniform float _MaxDistance; //The maximum distance A few sampler2D's for the dust and detail textures, and a float that will control the maximum detail distance. Currently the ring shader used by Kopernicus looks up the color of the main texture and stores it in a Vector4, 'color', then works some shadow and scattering magic on it. I have added a few lines before this effect magic however. float4 _RingDetail_var = tex2D(_RingDetail, i.texCoord); float4 _DustLarge_var = tex2D(_DustLarge, i.texCoord); float4 _DustSmall_var = tex2D(_DustSmall, i.texCoord); //Get the distance between ring and camera //Saturate = clamp between 0 and 1 //Divide MaxDistance by Vector3.Distance(vertPos, camPos) float Distance = saturate((_MaxDistance/distance(i.posWorld.rgb,_WorldSpaceCameraPos))); //Get the diffuse color float3 dcolor = lerp(color.rgb,max(saturate((color.rgb > 0.5 ? (1.0-(1.0-2.0*(color.rgb-0.5))*1.0-_RingDetail_var.r)) : (2.0*color.rgb*_RingDetail_var.r)) ),(_DustLarge_var.rgb+_DustSmall_var.rgb)),Distance); /* Color dcolor = Color.Lerp( (main texture W.O. effects), (main texture W. effects), Distance); (main texture W. effects) = max( Mathf.Clamp01( (color.rgb > 0.5 ? (1.0-(1.0-2.0*(color.rgb-0.5))*1.0-_RingDetail_var.r)) : (2.0*color.rgb*_RingDetail_var.r))), (_DustLarge_var.rgb+_DustSmall_var.rgb)) Ergo blend mainTex and ringDetail with a hard light mode, then feed the result and the sum of the dust textures to a max function so the dust is applied on top of the ring texture. */ // Combine material color with texture color and shadow dcolor.xyz = _Color * shadow * (dcolor.xyz * dotLight + dcolor.xyz * mieScattering); fixed4 finalRGBA = fixed4(finalColor,lerp(color.a,(color.a*_RingDetail_var.g),Distance)); return finalRGBA; I'm not sure about the way I handled the alpha channel, I'm afraid I'm shooting @blackrack's amazing scattering effect in the foot there. This is the full edited shader: Could someone check my edits for errors? Of course, I'll be testing this shader, but if someone spots a flaw in advance, then I can fix it right away.

Some images of the ring detail in action. Left: my detail shader; right: Unity built-in Standard shader Note that this is without distance filtering. Here is a closeup comparison: And here is a demonstration of the distance value. Because yes, the maximum detail distance can be changed easily. From up-close: From afar:

Update to my previous post: - The shader now has TWO dust 'detail' textures, so users can make both large and small particles applied on top. - The shader now has a 'ring' detail texture besides the dust textures, ergo, from up-close rings appear subdivided into several smaller rings - The shader now fades based on distance. The math behind the shader is as follows: I'm now going to try to merge it with the Kopernicus ring shader. The biggest problem will likely be the way how Kopernicus wraps ring textures. I'll be posting a few images showing my shader in action later.

I've done some further testing with shaders. For this I tried downloading the ring shader Kopernicus uses from GitHub and making changes for testing purposes on a local copy, but Unity does not approve. Thus I decided to write a simple shader using the Blinn-Phong lighting model. After all, all I'm trying to do is fading textures, which doesn't require anything fancy. I imported Cyran's ring texture as well as a dust texture I made in GIMP in a minute, and fed them to the shader. I found two promising results: This was done through a 'lighten only' algorithm, where the dust map is only added if the pixel on the dust map is lighter than that of the ring texture. Because we're dealing with white dots on a black background, this yields a result similar to basic ring dust. This one is even simpler. The function for this is: E = R+D Where E is resulting color, R is ring tex color, and D is dust color. Because the dust has a black background, the addition does nothing there, but this isn't the same fo the dust particles themselves. Granted, this is a very basic approach and doesn't have any fancy distance-fading, but it's a start.

BEWARE Mios... (No joking, I showed Jeb that thing and he was too afraid to eat even pudding cups)

I'm just gonna, uh...