[1.9.x] Textures Unlimited - PBR-Shader, Texture Set, and Model Loading API

[Electrocutor]

@Shadowmage I get the feeling that the KSP render wiki is a long way out of date, could you see if my list needs updated compared to what you know?

        public enum KSPLayer
        {
            Default = 0,
            TransparentFX = 1,
            IgnoreRaycast = 2,

            Water = 4,
            UI = 5,


            PartsList_Icons = 8,
            Atmosphere = 9,
            ScaledScenery = 10,
            UI_Culled = 11,
            UI_Main = 12,
            UI_Mask = 13,
            Screens = 14,
            LocalScenery = 15,
            kerbals = 16,
            Editor_UI = 17,
            SkySphere = 18,
            DisconnectedParts = 19,
            InternalSpace = 20,
            PartTriggers = 21,
            KerbalInstructors = 22,
            ScaledSpaceSun = 23,
            MapFX = 24,
            EzGUI_UI = 25,
            WheelCollidersIgnore = 26,
            WheelColliders = 27,
            TerrainColliders = 28,


            Vectors = 31
        }

 

[Shadowmage]

The most up-to-date information that I have on the subject can be found here:

^^^ is the resource that I use when dealing with layers/tags; I don't personally keep track of that information anywhere as I very rarely need it.

[Electrocutor]

3 minutes ago, Shadowmage said:

The most up-to-date information that I have on the subject can be found here:

^^^ is the resource that I use when dealing with layers/tags; I don't personally keep track of that information anywhere as I very rarely need it.

Thanks; I'm surprised you don't use them to make a cull mask.

[Shadowmage]

40 minutes ago, Electrocutor said:

Thanks; I'm surprised you don't use them to make a cull mask.

I'm guessing that is something IVA related? (for the flight-scene cutout rendering?)  I just pretend that IVAs don't even exist, and keep on driving....

[Electrocutor]

1 minute ago, Shadowmage said:

I'm guessing that is something IVA related? (for the flight-scene cutout rendering?)  I just pretend that IVAs don't even exist, and keep on driving....

err no... it's what Unity uses to choose what things to render. For example, this is my reflection probe code:

            ReflectionProbe oProbe = oVessel.gameObject.AddComponent<ReflectionProbe>();

            List<KSPLayer> oLayers = new List<KSPLayer>() {
                KSPLayer.Atmosphere,
                KSPLayer.LocalScenery,
                KSPLayer.ScaledScenery,
                KSPLayer.ScaledSpaceSun,
                KSPLayer.SkySphere,
                KSPLayer.Water
            };

            oProbe.mode = UnityEngine.Rendering.ReflectionProbeMode.Realtime;
            oProbe.refreshMode = UnityEngine.Rendering.ReflectionProbeRefreshMode.EveryFrame;
            oProbe.timeSlicingMode = UnityEngine.Rendering.ReflectionProbeTimeSlicingMode.IndividualFaces;
            oProbe.cullingMask = GetCullingMask(oLayers);

 

[Shadowmage]

15 minutes ago, Electrocutor said:

err no... it's what Unity uses to choose what things to render.

Oh, yes, those.  Certainly I do use them, just different syntax than you posted -- https://github.com/shadowmage45/TexturesUnlimited/blob/master/Plugin/SSTUTools/KSPShaderTools/Addon/ReflectionManager.cs#L14-L18

Notably I just bit-bash the layer #'s rather than using the Unity 'name to layer mask' functions.  IDK, just more comfortable when I know exactly what the code is doing (and I often don't know about the existence of the Unity utility functions... until I've already written my own).

[Shadowmage]

Worked a bit on the updated shaders variants that will be available for 1.5+.  Fairly certain that I have the standard TU-Metallic shader all figured out and working -- lots of new features, mostly recoloring related.  Should support all of the existing setups used in the SSTU/PBR/Masked and SSTU/PBR/Metallic shaders, plus quite a few more.  I'll be working up some documentation and examples prior to release.

Also working on two more shader variants -- TU-Specular (Unity Standard-Colored Specular Workflow), and TU-Legacy (Blinn-Phong Colored Specular).  These will have all of the same 'features' as the TU-Metallic, but with different inputs and/or lighting models.  You won't exactly be able to just switch between them, but they will be as consistent as possible given the differences in features and texture use.

Each of these will also have a transparent counterpart to support alpha based transparency.  Six .shaders in total (plus a few technical shaders not needed by users).

The list of common features is --

• Smoothness source selection - spec.a, spec.r, diff.a
• Enable/Disable bump-mapping
• Enable/Disable emissives (window glow)
• Enable/Disable Sub-surface scattering
• Enable/Disable AO-Map sampling
• Select Recoloring Type -- OFF, STANDARD, TINTING
• Select Recoloring Normalization - OFF, SPEC/MET, INFLUENCE, SPEC/MET+INFLUENCE

Recoloring has a new system -- 'normalized'.  It is much like the system used by SSTU, but allows you to specify the 'flat color' used in the diffuse texture, to facilitate the extraction of details in user-masked/recolored pixels.  It has the ability to use a texture to specify the 'normalization' values, as well as per-recoloring-channel parameters to specify flat values.  The 'legacy' recolor textures used by SSTU is directly mappable to this new input mode by simply specifying a flat normalization value in the newly exposed parameters (no normalization texture needed).  The normalization textures will really only be needed for much more complex recoloring/masking setups -- most setups (including the work done by @Manwith Noname) should be able to use the new system successfully by only using the parameters.

Hoping to have these shaders finished and ready for testing in the next day or two -- likely will be available with the TU for KSP 1.5 release (though might do one last 1.4.x version with the recent fixes).

Edit:  Ohh.. did I mention that these shader packs now take ~2hrs to compile due to all the internal sub-variants?  May only be 6 shaders exposed to the user-side, but internally it compiles ~10k different variants.  The shader packs (compiled binary shaders) are also comparatively huge -- likely will be ~60mb for the full set (contrast to 340k for the existing shader pack...).

 

Edited October 16, 2018 by Shadowmage

[Shadowmage]

Front row is 'standard specular' shader variants, middle row is legacy blinn-phong, and rear row is metallic.  From the left, in each row, is subsurf-scattering (solar panels), tinted recolor, normalized recolor, and recolor disabled.

I had to 'create' some textures for the standard specular variant (hence the difference in windows), as the stock textures really only include the smoothness information (or maybe they only include a grayscale specular color, IDK which it is supposed to be).  I also had to create a metallic mask for the standard-metallic variant, but that was relatively simple.

Also found that the standard specular shader is....weird.  You can definitely specify unrealistic materials with it, and there is a strange 'mix' factor between specular light-color and diffuse color -- anything with a specular color should be darker in the diffuse texture... or else it is enforced by the BRDF by discarding the diffuse data.  While you can do some things with it that are not possible with the metallic shader, it is also much trickier to author textures for, and much harder to use in the recoloring system (lots more inputs to deal with).

For the legacy specular and standard specular, I added full specular color controls to the shader, which currently are not supported by the in-game recoloring system.  So I'll need to either add support for these shaders' recoloring setup to the existing GUI, or rework their recoloring to allow grayscale input via the metallic slider (which would control if specular reflection was white, or if the color was taken from the diffuse) -- essentially a kind of metallic workflow wrapper around the specular setups.  Seems like, for the sake of my sanity at least, that I'll be doing the latter -- some shader-side math to remap the metallic-slider as a spec-color mix factor  (if/when I create new UI for the recoloring system, I will take this under further consideration).

[Electrocutor]

I was tinkering with the new KSP shader and finally figured out why the parts didn't look right even after adding a reflection probe... ambient light. The ambient light slider needs to be off for the PBR to look right, otherwise the whole surface is mostly getting the same amount of light, which makes it look strange. After turning ambient light off, you can now get parts to look as good as TU in terms of lighting, minus the fact of having a flat smoothness.

I think that in the VAB/SPH, the point light is insanely bright compared to Flight, so you don't notice it there.

Turning off ambient light has it's own issues though: namely the old KSP shaders don't have the same indirect light calculation in them as the new one does: they just look black if not in direct light.

----

As for the size of the new shader, you may consider removing the keywords for things like bump, emissive, etc to reduce the permutations. I think diff+bump+metal/gloss can be assumed to always be present, AO shouldn't take much juice to just be static if not present. Is there ever a case when you would use standard vs tinting mode? as I understand it, the standard will always have a grayscale map for diff while tinting will convert diff to grayscale, or is the difference between base 127 and base 0? Honestly, spec.r for smoothness could go away, but you'd need to batch process the old maps, that could be considered a bug of the old shader because all maps that I know of for pbr have metal on R and smooth on A: perhaps leave it for with the intent to remove it after maps get converted.

Edited October 17, 2018 by Electrocutor

[Shadowmage]

18 minutes ago, Electrocutor said:

I think diff+bump+metal/gloss can be assumed to always be present,

Except on most stock parts... where half of those maps are missing.  Haven't even looked at mods, but I'd guess its a fairly assorted mix of setups there as well.  Certainly, I'll always use them on anything that -I- create... but I can't really do anything about others' materials setups.  So, for my use, I would be fine with those features being 'always on' -- but with people always worried about 'performance impact' so much from graphical enhancements, I'm doing everything I can to give opportunity for optimization.

19 minutes ago, Electrocutor said:

AO shouldn't take much juice to just be static if not present

'Doesn't take much' is still more than 'has zero impact when not being unused'.  Texture samples are not 'cheap', and it was the sampling I was trying to avoid by blocking it out by keyword.  I'm not sure if there are some optimizations in place for when sampling from an empty texture slot, but it is exactly that which I was trying to eliminate.  Especially as 95% of the mods out there -don't- use separate AO maps, would be silly to run the code in those cases.

Sadly, I'm not familiar with any tools for real profiling to test any of this out.  If you happen to know of any, I would love to do some analysis on my shader code.

58 minutes ago, Electrocutor said:

Honestly, spec.r for smoothness could go away, but you'd need to batch process the old maps

Yeah, I've been debating on if it is needed -- at this point I'm just using it so that I can test stuff using some of SSTU's existing textures that were authored for that setup.  As the old shaders will still be around for anyone who can't update their textures, I likely will drop that functionality and just enforce unity-standard channel mapping for use with the new shader.  (I'll still support diffuse.a for spec/smooth data, as that is one of Unity's standard setups)

 

I'm not too hurt by the long compile times; it only takes that long when building the bundles for use in KSP -- in-editor refreshes of the shader take a moment, but are quick enough to not disrupt workflow too badly.  It means I'll be limited to doing releases on the weekends when I have time to let it compile, but that is already my current dev/release/packing time, so no real pain there.

More it is the extremely large file-size that is giving me more reason for concern.  The current mod is a very 'lightweight' package of a few hundred kb, so having it bloat into the 30-60mb range might give cause for hesitation for others wanting to bundle it for distribution.  This bloat is caused entirely by the massive number of shader variants that are being compiled;  -some- of these I might be able to disable/skip as they are features unused by KSP (such as directional light-mapping... pretty sure KSP doesn't use that), but will require a ton of experimentation to determine precisely what I can disable.

 

 

22 minutes ago, Electrocutor said:

Is there ever a case when you would use standard vs tinting mode?

Rather it is the other way around -- tinting mode is now mostly 'obsolete' when compared to what is possible with the new 'standard' recoloring mode.  Though, basically, the 'main' difference is in how colors are blended.  Standard mode uses addition with clamping, tinting mode uses multiplication (output will always be darker than the input).

Actually I wrapped that code in proper functions in the shaders now, so can share the functional bits of the code easily.

Tinting mode:

inline fixed3 recolorTinting(fixed3 diffuseSample, fixed3 maskSample, fixed3 userColor1, fixed3 userColor2, fixed3 userColor3)
{
	fixed mixFactor = getMaskMix(maskSample);
	fixed3 userSelectedColor = getUserColor(maskSample, userColor1, userColor2, userColor3);
	fixed3 detailColor = diffuseSample * (1 - mixFactor);
	return saturate(userSelectedColor * detailColor + diffuseSample * mixFactor);
}

Standard mode ('norm' is a normalization value taken from an optional texture and/or shader parameter; in SSTU recoloring, that value will be set in the texture-sets to 0.5f for 'flat gray'):

inline fixed3 recolorStandard(fixed3 diffuseSample, fixed3 maskSample, fixed norm, fixed3 userColor1, fixed3 userColor2, fixed3 userColor3)
{	
	fixed mixFactor = getMaskMix(maskSample);
	//the color to use from the recoloring channels
	fixed3 userSelectedColor = getUserColor(maskSample, userColor1, userColor2, userColor3);
	//luminance of the original texture -- used for details in masked portions
	fixed luminance = Luminance(diffuseSample);
	fixed3 detailColor = ((luminance - norm) * (1 - mixFactor)).rrr;
	return saturate(userSelectedColor + diffuseSample * mixFactor + detailColor);
}

(note these posted functions are only for the diffuse/albedo color; specular/smoothness/metallic values have nearly identical functions with non-vector input/outputs)

Basically, the normalization functions because float/fixed values in the shader are allowed to go negative during intermediate calculations.  Take the original texture color, converted to luminance, and subtract the 'normalization' value -- this should get you a grayscale value, with zero as its 'mid-point', that can easily be used as a 'detail' input.  Anything >0 is a highlight, anything <0 is a shadow; simply add that detail value onto the users specified color, and you now have what should be near-exact color fidelity and the details from the original texture.  Yes, it is still possible to 'clamp' out some of the details if the user selects a very bright white (highlights will be clamped, or very dark black color (shadows would be clamped)-- but that is the users' error for selecting a non-realistic color to begin with.

 

26 minutes ago, Electrocutor said:

as I understand it, the standard will always have a grayscale map for diff while tinting will convert diff to grayscale,

You are mixing them around I think.  The new standard mode does not require a grayscale input -- it requires that you supply an additional texture or parameter data to normalize the base textures into the desired format to use for detail maps (actually not required, but is how you will get 'good' outputs). Now, the new 'standard' recolor mode will be perfectly happy if you do supply it with grayscale texture inputs, you'll merely have to also set the normalization parameters to account for it -- and in fact this is how I'll be using it for SSTU.  The old 'grayscale' recoloring system is gone in the new shaders.  Nobody but SSTU used it that I'm aware of, and it will still be available in the legacy shader pack.

Tinting mode is exactly what it is in current versions -- take the existing diffuse color and multiply it by the user-specified color on masked pixels.  Just as if you had a per-mask-section _Color parameter.  Very tempted to get rid of it as well -- the legacy shader pack will still be available for anyone who wants to use that shader/recoloring mode.  The new standard/normalized system might operate slightly differently, but it is in my opinion a far, far, better method than color multiplication, even when not using full normalization textures and just using the section-based parameters.

 

51 minutes ago, Electrocutor said:

even after adding a reflection probe... ambient light.

Ahh, yes, that would make sense.  KSP shaders all have extra code to handle the stock 'ambient light boost' functions.

Also noticed when examining the stock shaders, that they all have manually coded support for 'underwater fog' -- which is something I'll need to add in to ensure full compatibility.  Will look at adding the stock ambient-light-boost functions as well (even if I don't agree with the entire premise).

[Electrocutor]

23 minutes ago, Shadowmage said:

Except on most stock parts... where half of those maps are missing.  Haven't even looked at mods, but I'd guess its a fairly assorted mix of setups there as well.  Certainly, I'll always use them on anything that -I- create... but I can't really do anything about others' materials setups.  So, for my use, I would be fine with those features being 'always on' -- but with people always worried about 'performance impact' so much from graphical enhancements, I'm doing everything I can to give opportunity for optimization.

I just meant that processing these using the default flat map would be fine instead of turning the feature on and off. If they don't even have a bump map, why would they bother with metal/gloss, and if they don't use metal/gloss, why would they even be using this shader in the first place? Even stock uses metal/gloss with metal at a fixed multiplier and gloss at diff.a.

Edited October 17, 2018 by Electrocutor

[Shadowmage]

7 minutes ago, Electrocutor said:

If they don't even have a bump map, why would they bother with metal/gloss, and if they don't use metal/gloss, why would they even be using this shader in the first place?

LoL, I fully agree... and might just make that move.  Cutting out those 2-4 keywords would trim the variant count exponentially.

[Shadowmage]

Crazy...

Removal of the TU_EMISSIVE, TU_BUMPMAP, TU_AO, TU_LEGACY_SPEC, and TU_RECOLOR_TINTING keywords brought the variant count from 5800 for the legacy shader, down to 366.

The remaining features are for control of smoothness input source (diffuse.a or spec/met.a), subsurface scattering, and to enable recoloring mode and its sub-features.  So only the computationally expensive or input-altering keyword features remain.

If I were to skip unused features for KSP, I could likely get that down a lot further, in the sub 100 range.  For reference, the legacy SSTU/PBR/Masked shader has 76 internal variants, with nearly all of those from the built-in keywords.

[Shadowmage]

Variants cleaned up, bug regarding normalization parameters fixed (texture inputs worked), recoloring for StandardSpecular and LegacySpecular adjusted a bit to utilize metallic slider in the GUI.  Legacy doesn't support it the best, but if you really want metallics... use the new shaders.

Will likely be compiling these in the next day or two, and move on to working on the transparent variants.

[Shadowmage]

Shaders compiled and working; with the trimmed down variants its only a ~1mb pack.  Might hit 2mb with the inclusion of the icon shaders, though I haven't quite sorted out how those will be done yet.

 

TU/Specular shader works quite well with the new stock probe -- it apparently has a valid and fairly well done smoothness mask in its spec-map alpha channel.  After plugging it all into the shader, with zero additional tweaks, the results are quite impressive.  Makes me wonder why stock put together their shader as they did, if they already had at least some art assets of this quality.  Perhaps they didn't want to raise the bar too far? (and/or, more likely, the DX9 issues)

I'd use stock parts if they all looked like this ^^

Edit:  probably the best stock texturing job I've seen, if it were to be fully utilized

 

 

I'll be pushing this all onto the /dev branch tonight if anyone wants to give it a go.  Won't be any documentation available until at least the weekend, but I think the feature-set has been stabilized for now.

 

Edited October 18, 2018 by Shadowmage

[Shadowmage]

More update regarding the new shaders --

I've also remapped the channel inputs for AO to read from the GREEN channel of its input texture.  So you could, in theory, use a single input map for your metallics (R), AO(G), ??(B), and smoothness (A).  Now, when setting it up this way with DDS textures and multiple channels used for different data, there -will- be artifacts from cross-channel bleedthrough due to the compression...but it shouldn't be any worse than converting recoloring mask textures to dds.

 

[blowfish]

15 hours ago, Shadowmage said:

More update regarding the new shaders --

I've also remapped the channel inputs for AO to read from the GREEN channel of its input texture.  So you could, in theory, use a single input map for your metallics (R), AO(G), ??(B), and smoothness (A).  Now, when setting it up this way with DDS textures and multiple channels used for different data, there -will- be artifacts from cross-channel bleedthrough due to the compression...but it shouldn't be any worse than converting recoloring mask textures to dds.

If there's something in particular that's likely to be independent of the rest maybe it's worth putting on the alpha channel since that's independent?  For instance I'd expect some correlation between metallicity and smoothness but none with AO

[Electrocutor]

5 hours ago, blowfish said:

If there's something in particular that's likely to be independent of the rest maybe it's worth putting on the alpha channel since that's independent?  For instance I'd expect some correlation between metallicity and smoothness but none with AO

Having metal on red, smotthness on alpha, and ao on green is pretty standard for PBR textures though: I think his goal is to standardize the shader with how most PBR works. For example, with this setup, I can now directly make a PBR version of Porkjet's PartOverhaul because he already had all of this made.

[Shadowmage]

7 hours ago, blowfish said:

If there's something in particular that's likely to be independent of the rest maybe it's worth putting on the alpha channel since that's independent?  For instance I'd expect some correlation between metallicity and smoothness but none with AO

In theory I think that would be the better setup, reduce the cross-channel artifacts to related textures.  Sadly, that is not the setup that most other engines I've looked at use, and I'm trying to get this version to be a bit more standardized.

I wouldn't even mind adding in the keywords/variant stuff to allow for per-input channel specification, except for the shader pack bloat that very quickly adds up.

1 hour ago, Electrocutor said:

Having metal on red, smotthness on alpha, and ao on green is pretty standard for PBR textures though: I think his goal is to standardize the shader with how most PBR works. For example, with this setup, I can now directly make a PBR version of Porkjet's PartOverhaul because he already had all of this made.

^^ Pretty much this -- is why I did it.

If I were to be add parralax/height-mapping, I'd probably have that on the blue channel of the same texture... might as well pack it full.  Of course, the option still exists to use full RGB channel grayscale inputs for each of these slots (they don't all have to be packed in a single texture), so its really up to the texture author on how much cross-channel artifacting is acceptable, and in which textures.

 

Managed to get the icon and transparent versions of the shaders compiled and packed up last night.  /dev branch should now be in a bout a 'pre-release' state as far as shader and plugin code go.  May still need to adjust the shaders a bit to add in support for stock ambient light boost ( ), and stock underwater fog.  I'm personally not too fond of either feature, but it shouldn't add to much overhead to support them.

As a bonus, I fixed up the Windows OpenGL part-icons with the new icon shaders -- no more part-clipping in the editor parts list.  Not sure if I just pushed the problem to OSX/Linux versions or what....  stock fixes it by OS and not graphics API, which is why when they 'fixed' the mac openGL version, they 'broke' the windows OpenGL version; I've now fixed the windows openGL version... but probably broken linux/mac.  I've also expanded the target-shader list for icon-shader replacement, so the TU icon shaders will be used on most stock parts.

Documentation is mostly written up, on the TU repository wiki -- https://github.com/shadowmage45/TexturesUnlimited/wiki.  Need to expand on the subsurf and recoloring systems, and add in example assets for use in the tutorials.

[Shadowmage]

While I've been working on updating the shaders and adding features, I've also been deliberating on adding some post-processing effects to TU (or as another small mod).  Essentially some parts of what KS3P does.... but functional with OpenGL and DX11 (as the KS3P author has expressed no desire to make it functional on either platform last I checked), and with a much simpler to set up and use config system (as well as an in-game GUI for real-time tweaking and generation of configs).

Is there anyone else who would be interested in Bloom, Motion Blur, Depth-of-Field and Screen-Space Ambient Occlusion effects?  I'm not personally interested in tone-mapping, eye-adaption, or vignette.... though might consider implementing them as well (esp. if I just do as KS3P did and import the entire PP stack).

Fairly certain that I'm going to be doing this for myself, either way, but if there is enough interest in the features I will consider including it in TU or spinning it off as a new stand-alone mod.  Would really rather not  make a new stand-alone, as KS3P is already there for filling that need, but it is an option.  I'd also be willing to contribute the work back into KS3P if the author was receptive to it... but first he would have to completely redo his config system (which is one of the major reasons I won't use it as-is).

[Gordon Dry]

36 minutes ago, Shadowmage said:

as the KS3P author has expressed no desire to make it functional on either platform last I checked

Which imho is weird - because DirectX 9 da fuq?

37 minutes ago, Shadowmage said:

tone-mapping, eye-adaption, or vignette

neither

[Electrocutor]

40 minutes ago, Shadowmage said:

While I've been working on updating the shaders and adding features, I've also been deliberating on adding some post-processing effects to TU (or as another small mod).  Essentially some parts of what KS3P does.... but functional with OpenGL and DX11 (as the KS3P author has expressed no desire to make it functional on either platform last I checked), and with a much simpler to set up and use config system (as well as an in-game GUI for real-time tweaking and generation of configs).

Is there anyone else who would be interested in Bloom, Motion Blur, Depth-of-Field and Screen-Space Ambient Occlusion effects?  I'm not personally interested in tone-mapping, eye-adaption, or vignette.... though might consider implementing them as well (esp. if I just do as KS3P did and import the entire PP stack).

Fairly certain that I'm going to be doing this for myself, either way, but if there is enough interest in the features I will consider including it in TU or spinning it off as a new stand-alone mod.  Would really rather not  make a new stand-alone, as KS3P is already there for filling that need, but it is an option.  I'd also be willing to contribute the work back into KS3P if the author was receptive to it... but first he would have to completely redo his config system (which is one of the major reasons I won't use it as-is).

I'd say Bloom and Lens Flare are the biggest ones for a PBR shader. The other would be the one that over-exposes shiny edges (and subsequently cause bloom and lens flare due to the brightness), but I don't know what that's called. SSAO is only ok if you can optimize it well; staticobject-terrain, intra-vessel, and vessel-terrain (EVA is a vessel).

 

----

Unrelated: I'm working on making the reflection probe 1.5.0 fix work with EVE and Scatterer. Scatterer just straight up blacks-out all rendering layers, so no idea what's up there; but where in the world are the clouds from Eve going? They are not being applied to the atmosphere or scaledspace layers at all.

Edited October 19, 2018 by Electrocutor

[Gordon Dry]

I also can relinquish Motion Blur and Depth-of-Field.
So I am totally okay with bloom, AO and lens flare.

[Shadowmage]

39 minutes ago, Electrocutor said:

Scatterer just straight up blacks-out all rendering layers, so no idea what's up there;

Yep -- is why (part of) I had to use the camera - sphereSkyBox - reflectionProbe setup.

Scatterer itself is applied as a post-processing effect to all renders, so when the reflection probe does its captures, it is getting scatterer all-over.  Only, scatterer only works if its shader properties have been setup for the specific camera orientation/etc for every frame.  I personally didn't get 'full black' but rather incorrect atmosphere in most frames; though it was also terribly inconsistent and dependent on view orientation, how long in the scene (due to world transform), etc.  To fix this, you need to name your camera something special - 'TRReflectionCamera', as this causes code in Scatterer to skip rendering for that camera.  (so in your case, you would have to hack Unity to rename the camera source that the reflection probe is using, which is not likely to be possible from my experience).   https://github.com/shadowmage45/TexturesUnlimited/blob/master/Plugin/SSTUTools/KSPShaderTools/Addon/ReflectionManager.cs#L211

39 minutes ago, Electrocutor said:

but where in the world are the clouds from Eve going? They are not being applied to the atmosphere or scaledspace layers at all.

They are rendered in a different 'layer' than the stock atmospheres.  Umm... IDK what I had to do to solve that, but IIRC it was re-ordering the layered rendering I was using to render them after some other layer.  Will look at my code and see if I can decipher precisely what it was I did for that.

There is also the problem of EVE shaders writing '0' into the alpha channel anywhere that a cloud is casting shadows, but that might not be an issue with the render probes (I was compositing textures, so these zeros were causing the previous pass to show through).

Edit looking at my multipass rendering, it is done such as this:

First pass is galaxy box only (layer 18 - SkySphere)

Next it renders layers 9 + 10 in the scaled space + atmosphere pass.  Eve could be rendering to one of those (9=atmosphere, 10=scaled scenery).

Last it renders to layers 4, 15, 17, 23 in my 'local scenery' pass (the last pass)  Looking it up, that is 'Water', 'Local Scenery',  'EVA'???, 'AeroFXIgnore'???  (not sure why those last two; could be EVE was in 17+23)

 

Edited October 19, 2018 by Shadowmage

[Electrocutor]

I may have found part of the issue: it looks like the Unity camera is either blending layers instead of stacking them or is creating some sort of artificial far cut-off that is much, much shorter than I specify.

For example, if I set the camera to only show layer localscenery, then I see everything all around the pad (vab, sph, towers, hills and mts in the background, etc; but if I add the atmosphere to that, I only see about 10 meters around me in local scenery and the rest is cut off.

(I am not seeing any clouds when I set a camera to any of those layers you mentioned above, so not sure what the deal is there).