Electrocutor

Textures Unlimited doesn't do anything on its own. It is a mod resource that includes a bunch of PBR shaders. I intend to eventually release a StockPBR mod with all that, but it is a lot of work trying to make normals and metal maps for all the stock textures, especially when I am no artist and the graphics tools are clunky in my hands. ---- @Ger_space I have a couple of things I've thought about while tinkering with all this: I'd like to know your thoughts in response to them... Combine Kerbinside, Extraplanetary Launchpads, Ground Construction, Kerbal Konstructs, and Modular Launchpads into a single mod where the authors each work on the parts they are best at, while the mod uses a single interface across all of these construction/building based mods. The VAB and SPH editor scenes have full-blown interiors for those two buildings: why not open up the front doors and add the interiors while in flight mode, while making the windows all transparent like real buildings? Since it's just a bunch of models without collisions or physics, it shouldn't affect fps much (if at all). You can use the TU shader to mask the windows and make them transparent while the rest of the mesh stays opaque.

So... in a PartModule during the flight scene, the onLoad is the first method that fires that includes the config data for the PartModule; before this event, the KSPFields are newly initialized. However, the onLoad method fires after the part's models and textures have already been drawn. On the other hand, the first time onAwake fires is before the part is drawn, but there is no config data or fields available during the first fire because they have not loaded yet. ---- Does anyone know a way around this issue or if there is another method somewhere to force the part to redraw?

Added ModulePartVariantsEx/Internal to EXTRA_INFO to set the IVA. This obviously requires that you add the ModulePartVariantsEx to the part that needs IVA switching. No parameters are needed, it just acts to store and load the values. It will also be used to store/load all future values of things otherwise not persistent. MODULE { name = ModulePartVariantsEx baseVariant = base VARIANT { name = base EXTRA_INFO { ModulePartVariantsEx/Internal = baseIVA } } VARIANT { name = OtherIVA EXTRA_INFO { ModulePartVariantsEx/Internal = variantIVA } } } MODULE { name = ModulePartVariantsEx }

Any stats that are at the PART level of a part cannot be altered (except for mass and cost via the stock variant partmodule). This is because none of that data is persisted: it looks back at the original universal part instead of the instance to get that info. That means that for those other stats, it would need a PartModule to be able to persist and apply the changes (like tweak scale does for size). I'd be willing to make such a PartModule to compensate for the other things, but it hasn't been a priority yet as no one asked. I've already released it in its current form on my thread. No one showed any interest, so I haven't done much with it since, and started working on KSC PBR instead, but if you run into any issues let me know and I can help you through them or code against them if need be. Due to how engines work, making a variant engine is probably starting off with the most difficult task, so you'll need to pay close attention that everything is working as it should be.

So... Ever since the last Windows Update, -force-opengl and -force-glcore have been crashing on me regularly; so I'm going to have to downgrade -force-glcore from the most stable to unstable.

I've not had a single CTD in dx11 mode. I do not mean scatterer by itself. Reproduce: Setup: Fresh + Kopernicus, EVE, Scatterer Run with -force-glcore Use the following code and look at something about the shader, such as its name: Shader[] oShaders = Resources.FindObjectsOfTypeAll<Shader>(); It only CTDs with Kopernicus, EVE, and Scatterer installed; other mods that add and use shaders have no issue. I didn't bother to figure out which of the 3 was actually blowing up, so it may not be scatterer; but running in dx11 mode has no problem and all 3 worked fine, so I just ignored it. [Update] Trying various things... I've come to a conclusion: this is unrelated to Kopernicus, EVE, and scatterer. Ever since the last Windows Update, -opengl and -glcore have both becomes extremely unstable. This is not exclusive to KSP either.

dx11 is actually more stable than dx9, but the icons are broken unless you drop TU into your install. opengl and glcore will CTD instantly if scatterer is installed and you even query all shaders (not even using them), but if in dx11 or dx12 there is no issue. (I suspect you may have a half-corrupt shader in your bundle or something that makes opengl angry when unity tries to look at it). The most stable of all modes is glcore, but dx11 is a bit faster (both in load time and fps).

That's actually a good question: I had only consciously noticed it on Duna since that is my go-to planet for testing things. It's not an especially noticeable effect unless you are looking for it. I'll pay more attention when I install it again and see if I can see any specific patterns.

As far as I know, this has always been present on scatterer (might also be EVE related). At the very least both the last version and this, both dx11 and glcore. I rarely run d3d9, so am unsure if it too had the transparency on terrain. The amount of transparency changes with view angle.

To make a quick normal: Open the diffuse in GIMP Right-click, select Colors->Desaturate, select Luminosity Right-click, select Filters->Map->Normalmap Mess with various settings and test to see how they look There are better auto-bump tools, but this one is very easy to use. For example, Crazy Bump gives better results, but it's no longer free. To add PBR integration: Create a mask texture Cover the parts that are metal with 255 red (leave the rest black) Set the alpha to the glossiness (glass and polished things are around 98%, aluminum is 75%, rough steel around 60%, paint/plastic around 30-40%, rubber is basically 0%) You may need to alter the colors of the diffuse; for example, many surfaces that attempt to look like steel are made to be almost black, which the PBR shader will take care of itself, so they should be changed to be the actual color of steel (around 127 gray, aluminum is 192 gray).

so... crazy bump helps, but I think it'd be much better if an actual artist were to make a bump map; otherwise just use all new textures that includes bump, metal, and gloss maps.

I'm working my way there, will mess with the details later. So far as I can tell, so long as you preserve the _Color property that is set by PQS, it works fine to switch shaders. The TU shader has a built-in normalization feature too, so you can turn any texture into a neutral-luminance recolor.

There are some caveats that need attention though: namely, the decals all have the background textures burned into them instead of being alpha; so we'd have to fix those or they look funny against the differences in normals. I'm trying to figure out which scenery shaders actually work and do what they say and which ones don't. I've also found a number of issues where the material has textures, colors, or settings in place, but the shader selected doesn't support them (i.e. they selected the wrong shader).

I'm running some of the stock textures through crazy bump to see if I can just mass-produce the missing assets and have them look decent; we'll see, but since there are a fair number of normals already there that just aren't showing up: that helps too.

Since KK uses the stock assets, it should. I just change the shader from KSP's scenery to TU. As a matter of note... there are quite a lot of Scenery shaders that say Bump in their name, but do not support any kind of bump map; same too with Specular shaders not showing any specular light. A good example is the launchpad grate. All I did was switch it to TU shader and turn metal on, and the bump map that has always been there magically starts working because the TU shader isn't broken.