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

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

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

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.

Be careful -- the probes don't by default work well with KSPs layered/multi-camera rendering -- things will look odd unless you do some hacks to get all the layers to render properly (e.g. atmosphere will be rendered in wrong place or orientation, skybox not present, z-fighting on the planets when in orbit... all sorts of fun).

Apparently, no, the stock systems do not support flight-scene reflections. You can use TexturesUnlimited though for the reflections (when it is updated/released), which works with the stock shaders, and -does- have flight-scene reflections (dx9 still hates cubemap blurring however.... so there are issues unless you use openGL/dx11 -- I suspect this is why KSP currently does not support flight-scene reflections, as they use dx9 by default)

Kind of... Due to the terrible stock reflection setup, if they author textures to look good with the stock shader/reflections... they'll end up with results like the stayputnik -- far less reflection when using proper reflection probes and convolved reflection maps. Just using the _Shininess property directly for smoothness -- no texture sampling or any other inputs. One of the most powerful features of PBR... and they leave it to a material-wide property.... That about sums it up... Its like whoever was writing these shaders didn't know what he was doing. Or was given an absurd set of 'requirements' from external sources. Either way, someone was out of touch with the functions/features of these shaders... Good point.. I really only looked at the StayPutnik. In that case there was an alpha channel in the specular texture, with different values than were in the RGB channels. Ohh... and the new shader did not use the value for whatever reason -- they sample the specular.rgb and use that for specular color, but they ignore the specular map alpha channel entirely.

Pretty sure the 'fix' for the stock-shader compatibility will be to patch the _Smoothness values to something more reasonable given the improved env. maps used by TU. This is with a value of 0.75 (default appears to be ~0.5 on this part) -- Stock shader, just using TU to patch the material properly (and handle reflection probes...). Another option might be to create a TU/Specular shader that uses the specular workflow. The stock textures appear to be authored with smoothness data in the specular-map alpha channel, so could leverage the existing information there to set the smoothness appropriately. Never did manage to get a dump of the environment map data used in the stock reflections. I'm convinced at this point though that they are only active in the editors, and not using any sort of convolution (just the 'blurring' caused by mip-map sampling). Will need to await confirmation from the devs that the lack of flight scene reflections are either a bug, or intentional.

More investigations, more questions..... and a few answers. Stock is not using reflection probes, but rather they are using the ability to specify a 'default reflection' environment map in the Unity render settings, and it is this environment map that the stock shader is picking up (and is what TU will pick up if reflection probes are not enabled). As near as I can tell this is only used in the VAB and SPH, and there are no reflections in the flight-scene (no cubemap is assigned to RenderSettings.customReflection, no reflection probes, and no skybox). @Manwith Noname Are you sure you didn't have TU installed in your screenshot above? As soon as I can get at these cubemaps and dump them to disk, I'll take a look at the MIP levels and see how the blurring/convolution is done. On an interesting note, I was able to find out where the clouds in the VAB/SPH are rendered at/from.... (just a cube-map used as a background...)

I'm seeing this same thing in my testing on 1.5 (completely stock, DX9). Environment reflections seem to only work in the editors. Outside of the editors, the parts reflect 'black'. Is anyone getting reflections on these parts in the flight scene?

Well, the (really) good news is that nothing in SSTU appears to have broken at a gross level. The existing plugin loads fine, and all of the functions that I've tested appear to work (see TU thread for examples). So there shouldn't be too much of a delay before an official 1.5 version... just need to get TU sorted out and the stock shader compatibility fixed up/figured out.

Whatever the reflection source is, it works fine with the TU shaders, at a technical level. If I disable all of TU's reflection-probe functionality, the shaders/materials seem to pick up the stock environment map. I can also confirm that the seams in the cubemap are only present on DX9 -- so they are either doing dynamic run-time map generation, or the problem with seams is inherent in the dx9 texture sampling and not baked into the prebuilt maps. However, the stock system is not capturing the environment as it should for use as a proper environment map -- notably it lacks lighting effects, so the reflection source seems extremely dark compared to what it should be (see the TU shot below for comparison). Still can't get it working in the flight scene though... I'm hoping someone is filing bugs about the above, because it doesn't seem to work regardless of what graphics API I use or what settings I try. TU reflection setup still works in editor: and flight scene However -- when the stock parts with the new stock shader use TU's reflection probes, they are not nearly as reflective (note it is still showing blue from the sky outside, but it is very dull)-- There are major differences between how Unity's reflection probe is doing the convolution/blurring, and whatever stock is using. I'm still trying to figure out exactly where the stock reflections are coming from and how they are generated, but I have a feeling that there are some 'quick hacks' at play somewhere to get the stock stuff working for DX9. Doesn't look too bad though, even if it is not as shiny as it should be. Might be something that I could patch to fix, even if it is just converting the stock parts to use a TU shader Still investigating. At this point it appears that there will be some 'incompatibilities' between TU and the new stock shader, but there might be some parts of the system that I can use to clean up some of the DX9 nastiness... if I can figure out where they are and how to make use of them. I likely won't be using the stock environment mapping as-is though, as it is not suitable for standard PBR texturing due to the difference in blurring/convolution (likely they are doing simple blurring/mip-map tricks rather than convolution).

No, not really. Just using the Standard shader BRDF to enable the reflections ( #pragma surface surf StandardSpecular ). The .shader file is available in the updated Part-Tools if you wanted to peruse it. TU loads just fine in KSP 1.5. There is definitely some conflict/overlap in functionality though, as the TU cubemaps (from the reflection probes) override whatever stock is using, and give some ugly mess (far worse than the stock setup), at least under DX9. My first course of investigation will be to compile a version of TU that simply loads textures/materials, but doesn't touch the reflection system, and see if I can get TU materials to pick up the stock reflection stuff. Then... I'm going to investigate the source of these reflections (Reflection Probes, pre-rendered skybox textures, ??). I'm in no huge rush on this. Obviously have a bit of stuff to sort out beyond the basic updating that I had imagined...

@Manwith Noname Interesting, must just be broken in my game then (un-modded steam installation that I use for grabbing game updates). Hmm... I bet there is a setting somewhere that controls it @Electrocutor You were correct in that they are using a standard shader variant. Customized StandardSpecular to be precise. Investigating the source of the reflection maps ATM. Almost certain there will be conflicts if we are both using reflection probes...

Quick recompile is available: https://github.com/shadowmage45/KSPRescuePodFix/releases/tag/1.4.2.12 Will update if/when any issues are found.