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

Good news is that this should no longer be an issue with the 1.5 versions of TU shaders -- they will support the stock ambient light boost (as soon as I get over the absurdity of it, and implement it), as well as the stock underwater fogging effects. The new 'normalization' feature of recoloring in the new shaders I think will be of great use to you. Will likely be sending out some PM's this evening/over the weekend to discuss it and make sure you know how to use it -- even without any additional textures it still offers far better recoloring than the tinting mode. Want to get the basic documentation written up first so I have some resources to use while trying to explain things (of course, the old tinting mode will still be available, so none of the old configs should break; but I would highly recommend any new configs be done with the new shader/features)

First issue -- a very brief examination reveals that something is spamming your log with this: [EXC 13:52:40.837] MissingFieldException: Field '.KSPParticleEmitter.pe' not found. Not SSTU related as far as I can tell (SSTU doesn't do -anything- with particles), but most likely a symptom of something being wrong with one of your other installed mods. (does nobody bother looking at log files when they have problems? I shouldn't have to be the one to spot really simple to find problems like this) Find and fix that problem, whatever it is, and if the issue still occurs, then please provide an updated log file. Edit: You also have this spamming your log: [EXC 13:57:35.220] FileNotFoundException: Could not load file or assembly 'ClickThroughBlocker, Version=0.1.6.3, Culture=neutral, PublicKeyToken=null' or one of its dependencies. In short -- you have a seriously screwed up installation that you need to clean up before I can provide any support. And more correctly -- remove all other mods besides SSTU and its dependencies, run the tests and THEN see if you have a problem. If so, let me know. If no problem exists in a clean install -- then your problem is not SSTU, but something else. Really, you should have done this before even reporting an issue.

I already said you have something wrong with your installation -- you are either missing dependencies, have wrong versions installed, incorrectly placed the files for the install, or there are other mods conflicting. Please provide the information requested above if you would like help with your problem.

Interesting information -- wonder if the issue is being caused by something engine specific (particles?), by the stock delta-v calcs, or something else entirely? That information at least should be enough for the devs to know where to start looking for the cause, assuming the issue is replicable(sp?) on other arbitrary installations. Does activating converters or other constant resource drain cause the same sort of performance impact? If it was simply vessel/part mass updates triggering the delta-v calculation, any changes to vessel mass should trigger the same kind of performance issues.

Ship the rocket parts up in a separate container. These modules are meant to be inflated after they have been delivered to their final destination. Once your deflated module is in orbit, dock a craft to it containing rocket parts (the qty needed will be specified in the right-click menu of the deflated module). Once the supplies have been docked to the station, right click on the deflated module, and press the 'Inflate' button. RocketParts will be consumed, up to the needed quantity, and if the need was fully satisfied, the module should inflate. You can also do partial deliveries -- if there is not enough rocket-parts when you press the 'inflate' button, it will consume all that it can and await the remainder to be delivered -- press the 'inflate' button again when the fresh supply is available. You have an error in your installation. Please provide a copy of your KSP.log file if you would like support in finding/fixing it.

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

Thanks for the confirmation. Will definitely take a look over these for the next update... which will hopefully be this weekend (just need to get TU all sorted out). Check your fuel lines and fuel-crossfeed. The pod is set by default to not cross-feed to lower stages. Try running a fuel line from the pod to the lower stage and see if that clears up the issue. Also -- check your fuel types; the fuel type in the pod needs to match what is used by your engine.

First they would have to remove the mandate that parts be joined together by flexible joints. Likely they would have to come up with a replacement system to allow for aero/physics based RUD that didn't rely on the joints breaking. They would also have to find a way to specify the proper mass distribution / inertia tensors for the single rigidbody that accurately reflected its 'bunch of separate parts' configuration. Certainly just that one change would eliminate a large portion of the physics load, instead of simulating one rigidbody per-part, you would have one per-vessel. Imagine being able to run a 1000+ part vessel with no noticeable slowdown? How about 5 of them at once? I've often been tempted to try and do such a thing through a mod -- but it would be a major undertaking, and I don't think that access is available for mods to adjust all the systems that would need to be changed. On a more positive note, I would like to give kudos to whomever at @SQUAD did the texturing work for the new Stayputnik -- when you plug the existing textures into a fully functional shader (and don't use dx9), the results are impressive. Truly well done It looks like the existing textures already include a smoothness map in the spec.a channel, and plugging it all into the Unity Standard (Specular) shader, you get a level of texturing artwork unseen anywhere else in KSP. There is a ton of detail in that unused smoothness map -- scratches, smudges, dirt/dust; someone spent some time and effort to create the map, but it just sits around unused by the stock shader.

Because it can't. It is not under the control of KSP -- it is part of Unity and PhysX. Edit: The reason it can't is because Unity does not support the per-object variable gravity setup needed. Hence, not a problem with KSP per-se, but a limitation in Unity. In this case, KSP is doing the best it can, given the engine it is using. (and no, I don't think any other commercial engines include variable per-object gravity vectors) Edit2: I'm not meaning to dismiss your concern, because it is perfectly valid -- the physics engine should do precisely such an optimization.

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.

That particular behavior is actually determined by Unity, and entirely out of SQUADs control. More specifically, Unity does not allow for specifying local varying gravity as would be needed by KSP (e.g. two probes within the same physics bubble will have slightly different gravity directions), so KSP has to apply gravity forces 'manually'. AFAIK, if a rigidbody (such as used in every Part in KSP) is being subject to an external force, the physics simulation will not let them 'rest'. Normally if a rigidbody is being effected only by gravity, but not moving (i.e. was landed), it will be put into a 'rest' state and physics calculations suspended until there is new external interaction (be it from collision, engaging an engine, whatever). TLDR: Unity physics simulation is not robust enough to handle KSP's physics requirements in an optimal fashion. Just thought I would clear up a few things regarding Unity and physics...

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.

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.

Are those the only parts you are having issues with, or does the problem effect other metallic parts as well? Also, a log file would help -- preferably the KSP.log that should be in the same folder as the executable. Upload it to a file-sharing site (dropbox, onedrive, google-whatever-its-called), and post the link here. Likely cause is that the reflection system is failing for one reason or another, and as metallic parts rely on the reflection for most of their visual look, without the reflections they appear 'black'..

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.

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

Thanks -- please let me know if it is working in some fashion, and/or what appears to be broken. Otherwise I'll assume it is 'broken entirely' when I begin investigating. Using RO by any chance? (if you click the 'Jettison' button, or activate it through action-group, it should auto-activate the jettison motors after a short delay)

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

I've examined the scene hierarchy and render setup. They are not using reflection probes at all currently, in any scene, and are only supplying pre-rendered cubmaps for the two editor scenes (which are being set through RenderSettings.defaultReflection). It appears intentional that there are no reflections in flight, and in fact, nothing dynamic in the current system for environment map source. Can't blame them though -- its a non-solvable problem in DX9, at a 'its broken in the Unity Engine' level. Even if you added 'real time'/dynamic reflection probes to the scene, the cubemap convolution under DX9 makes the reflections look absolutely terrible and worse than the legacy shaders. Yep -- Pretty sure I have it running in DosBox... on my phone

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

AFAIK it is still present and should work. There were a ton of plugin changes for the 1.4.x releases, and that function may well have been broken during the update. I'll open an issue ticket on it, and will investigate for the next release. https://github.com/shadowmage45/SSTULabs/issues/745

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