Iguas Posted September 8, 2021 Share Posted September 8, 2021 I just downloaded Texture Unlimited for the first time, and i'm a bit lost. Where can I find configs for this mod ? Note that i play heavily modded, and if possible, i'd like to get some parts supported. I tried Magpie's config and it doesn't work the way intended (most parts are very dark). Is it a TU or Config issue ? Thanks ! Quote Link to comment Share on other sites More sharing options...
Bellabong Posted September 11, 2021 Share Posted September 11, 2021 On 9/8/2021 at 7:59 PM, Iguas said: I just downloaded Texture Unlimited for the first time, and i'm a bit lost. Where can I find configs for this mod ? Note that i play heavily modded, and if possible, i'd like to get some parts supported. I tried Magpie's config and it doesn't work the way intended (most parts are very dark). Is it a TU or Config issue ? Thanks ! Magpie mods applies its settings indiscriminantly, even to plumes and engine glows, the mod itself is a bit borked; I spent the same amount of time fixing it as I would have spent making model configs from scratch. The reason they're meh is because it took the list of every model the game loads and gave them a generic config, and there's no real consistency with what parts are metal and what parts aren't. On top of that they're pretty out of date Quote Link to comment Share on other sites More sharing options...
FlybeachYon2021 Posted September 20, 2021 Share Posted September 20, 2021 Using this mod with Tundra Exploration will make the shiny gojira mk 4 Quote Link to comment Share on other sites More sharing options...
SpaceFace545 Posted September 27, 2021 Share Posted September 27, 2021 (edited) On 9/8/2021 at 6:15 AM, Bellabong said: Yeah, for Titan and Centaur you'd have to download the git version of the mod - the reason Titan and Centaur aren't included in the gif is because I'll be making changes that could potentially break crafts. The Atlas is fully integrated with the liveries from NIC and the configs of Agena/Titan integrate with the Delta Blue BDBNIC textures (if they're present, they incorporated into the TU texture switch menu, Atlas liveries don't require BDBNIC). The reason the Titan isn't in the zip yet is because I want to cut down its file size - all of its recolours could be represented by recolouring masks instead of having an entire set of metallic textures for each livery. Planning to have some fun with that and the Centaur this weekend And how do I download a git version? Edit: Well its just on the GitHub now, but I've experienced this with the titan. Only the lower stage and anything attached to that seems affected. Edited September 29, 2021 by SpaceFace545 Quote Link to comment Share on other sites More sharing options...
OnlyLightMatters Posted October 10, 2021 Share Posted October 10, 2021 Hi. I am trying to understand something. On the latest KSP release I have both TU and Kerbalism installed. I noticed there are side effects and about 6 parts of Kerbalism are automatically colored with a metallic shader. The detailed logs are: [LOG 13:26:59.387] Loading shader icon replacement data for: SSTU/PBR/Masked :: SSTU/MaskedIcon [LOG 13:26:59.388] Loading shader icon replacement data for: SSTU/Masked :: SSTU/MaskedIcon [LOG 13:26:59.388] Loading shader icon replacement data for: SSTU/SolarShader :: SSTU/MaskedIcon [LOG 13:26:59.388] Loading shader icon replacement data for: TU/Legacy :: TU/Icon/Legacy [LOG 13:26:59.388] Loading shader icon replacement data for: TU/Metallic :: TU/Icon/Metallic [LOG 13:26:59.388] Loading shader icon replacement data for: TU/Specular :: KSP/ScreenSpaceMaskSpecular [LOG 13:26:59.390] Loading shader icon replacement data for: TU/Transparent/Legacy :: TU/Icon/Legacy [LOG 13:26:59.390] Loading shader icon replacement data for: TU/Transparent/Metallic :: TU/Icon/Metallic [LOG 13:26:59.390] Loading shader icon replacement data for: TU/Transparent/Specular :: TU/Icon/Specular [LOG 13:26:59.390] Loading shader icon replacement data for: SSTU/PBR/Metallic :: TU/Icon/Metallic [LOG 13:26:59.401] TextureSet: Kerbalism_Metal did not have definition for mode (create/update). Using default value of: update. This may not function as desired, and may need to be corrected in the configuration file. [LOG 13:26:59.402] TexturesUnlimited -- Replacing textures on database model: KerbalismConfig/Parts/ChemicalPlant/ChemicalPlant [LOG 13:26:59.403] enabling TSMD..KerbalismConfig/Parts/ChemicalPlant/ChemicalPlant (UnityEngine.Transform) updateMode: True [LOG 13:26:59.404] Replacing empty textureslot: _MainTex with color: 0,0,0,255 [LOG 13:26:59.404] Replacing empty textureslot: _BumpMap with color: 128, 128, 128, 128 [LOG 13:26:59.404] Replacing empty textureslot: _Emissive with color: 0,0,0,0 [LOG 13:26:59.405] Replacing empty textureslot: _MetallicGlossMap with color: 255,255,255,255 [LOG 13:26:59.407] Updated material properties Can you explain what is exactly happening with the TextureSet and TexturesUnlimited. Where would Kerbalism_Metal come from? Quote Link to comment Share on other sites More sharing options...
Manwith Noname Posted October 10, 2021 Share Posted October 10, 2021 (edited) 4 hours ago, OnlyLightMatters said: Where would Kerbalism_Metal come from? It is supplied with Kerbalism. Edit: I will add, if you are thinking of creating recolour sets you can proceed without concern. Setting up recolour will override the KSP_MODEL_SHADER config. Edited October 10, 2021 by Manwith Noname Quote Link to comment Share on other sites More sharing options...
Delay Posted November 1, 2021 Share Posted November 1, 2021 Okay, so I tried updating my configs from... two years ago, to work with KSP versions that are newer than 1.6.1. And I've noticed that since 1.8.1, all models that do not have a _BumpMap defined have some rather funky shading applied to them. Applying a normal map from another part fixes it, so it's definitely the normals. I'll get a screenshot of that later, any ideas in the meantime? Quote Link to comment Share on other sites More sharing options...
Electrocutor Posted November 2, 2021 Share Posted November 2, 2021 (edited) On 11/1/2021 at 3:35 AM, Delay said: Okay, so I tried updating my configs from... two years ago, to work with KSP versions that are newer than 1.6.1. And I've noticed that since 1.8.1, all models that do not have a _BumpMap defined have some rather funky shading applied to them. Applying a normal map from another part fixes it, so it's definitely the normals. I'll get a screenshot of that later, any ideas in the meantime? I'm going to guess that something with the functions shadow used to try to compensate for the mass chaos that is KSP bump/normal maps affects materials with a null _BumpMap so instead of being set to "bump" default within the shader (RGBA: 0.5,0.5,1,0.5), it instead gets set to blank black or white. Unfortunately, no attempt was made to consolidate or standardize KSP's shaders, so it's mish-mash of customized shaders on different objects depending on when they were made. @Shadowmage made a config option called textureColor so you can use/assign that in any that are missing, but I forget the syntax and it's not in the wiki. Guess: MATERIAL { textureColor = _BumpMap, (0.5,0.5,1.0) } Edited November 2, 2021 by Electrocutor Quote Link to comment Share on other sites More sharing options...
Delay Posted November 2, 2021 Share Posted November 2, 2021 2 hours ago, Electrocutor said: @Shadowmage made a config option called textureColor so you can use/assign that in any that are missing, but I forget the syntax and it's not in the wiki. Unfortunately, that didn't work. I also tried working around the issue by actually making a default normal map and referencing it, but that didn't work either. Also, here's the screenshot I had promised yesterday. The cockpits are both correct as they have a bump map, but the same cannot be said for the tanks. Quote Link to comment Share on other sites More sharing options...
Electrocutor Posted November 2, 2021 Share Posted November 2, 2021 (edited) 4 hours ago, Delay said: Unfortunately, that didn't work. I also tried working around the issue by actually making a default normal map and referencing it, but that didn't work either. Also, here's the screenshot I had promised yesterday. The cockpits are both correct as they have a bump map, but the same cannot be said for the tanks. That's usually what TU would look like if you forgot to enable reflections. Please, verify that and also use DebugStuff to verify that all these parts are using TU to render. [Edit] It seems that Sarbian reverted to a much older version of DebugStuff that no longer has any model, material, or shader info... the mesh names are still present though. Edited November 3, 2021 by Electrocutor Quote Link to comment Share on other sites More sharing options...
Delay Posted November 3, 2021 Share Posted November 3, 2021 7 hours ago, Electrocutor said: That's usually what TU would look like if you forgot to enable reflections. Please, verify that and also use DebugStuff to verify that all these parts are using TU to render. I can verify that reflections are enabled (and working) and I can at least say that DebugStuff shows KSPTextureSwitch in the list for affected parts. Quote Link to comment Share on other sites More sharing options...
Electrocutor Posted November 3, 2021 Share Posted November 3, 2021 3 hours ago, Delay said: I can verify that reflections are enabled (and working) and I can at least say that DebugStuff shows KSPTextureSwitch in the list for affected parts. Please, post your config in a spoiler tag so I can see what's up. I tested with the mk2 tanks and none even needed me to specify a _BumpMap to show correctly. Quote Link to comment Share on other sites More sharing options...
Delay Posted November 3, 2021 Share Posted November 3, 2021 32 minutes ago, Electrocutor said: I tested with the mk2 tanks and none even needed me to specify a _BumpMap to show correctly. Well, the mk2 parts have specular maps defined, so I'm going to use two wings instead: Spoiler KSP_TEXTURE_SET { name = AirplaneFins MATERIAL { shader = TU/Metallic PROPERTY { name = _Metal float = 0.38 } PROPERTY { name = _Smoothness float = 0.275 } PROPERTY { name = _Color color = 1.15, 1.15, 1.15 } texture = _MainTex, Squad/Parts/Aero/airplaneFins/AirplaneFins } } @PART[CanardController|tailfin] { MODULE { name = KSPTextureSwitch textureSet = AirplaneFins } } "Standard Canard" and "Tail Fin" in the partlist. I'm worried that there is one minor thing I forgot and I've only wasted your time. Sorry if that's the case. Quote Link to comment Share on other sites More sharing options...
Electrocutor Posted November 3, 2021 Share Posted November 3, 2021 2 hours ago, Delay said: Well, the mk2 parts have specular maps defined, so I'm going to use two wings instead: Hide contents "Standard Canard" and "Tail Fin" in the partlist. I'm worried that there is one minor thing I forgot and I've only wasted your time. Sorry if that's the case. Okay, doing a couple tests I think I figured out what's up. Also, my suggestion of setting textureColor works perfectly fine. MATERIAL { shader = TU/Metallic float = _Metal, 0.38 float = _Smoothness, 0.275 color = _Color, 1.15, 1.15, 1.15 inheritTexture = _MainTex } This does not set the BumpMap. It looks like one of the parts ends up with a null BumpMap, while the other has a black BumpMap (why they act differently, I don't know). The null one will get set to Unity's "bump" by default in the shader, whereas the black one will just royally screw up the light direction. MATERIAL { shader = TU/Metallic float = _Metal, 0.38 float = _Smoothness, 0.275 color = _Color, 1.15, 1.15, 1.15 inheritTexture = _MainTex textureColor = _BumpMap, 0.5, 0.5, 1.0, 0.5 } This one sets the BumpMap to the default flat, the same as Unity's "bump" and works fine for both. As a side note, you only need to use KSPTextureSwitch if you provide multiple choices and want a selection; otherwise you should use KSP_MODEL_SHADER. Quote Link to comment Share on other sites More sharing options...
Delay Posted November 3, 2021 Share Posted November 3, 2021 2 hours ago, Electrocutor said: Okay, doing a couple tests I think I figured out what's up. Also, my suggestion of setting textureColor works perfectly fine. Yeah, textureColor as RGBA works like a charm! Thanks! Also, has inheritTexture been in TU all this time? That's not in the documentation as far as I've seen, would've been nice to know a bit earlier. I assume this also works with PartVariants having different models? Quote Link to comment Share on other sites More sharing options...
Electrocutor Posted November 3, 2021 Share Posted November 3, 2021 (edited) 16 minutes ago, Delay said: Yeah, textureColor as RGBA works like a charm! Thanks! Also, has inheritTexture been in TU all this time? That's not in the documentation as far as I've seen, would've been nice to know a bit earlier. I assume this also works with PartVariants having different models? If you combine a KSPTextureSwitch and stock PartVariant, I'm not sure which texture it will cache using inherit, you'd have to test. He added PartVariant support, but only got to alpha testing before it frustrated him, so it's a use-at-your-own-risk kind of thing. MODULE { name = ModulePartVariant VARIANT { EXTRA_INFO { textureSet = xxx } } } MODULE { name = TUPartVariant } inheritFloat and inheritColor have also been there Edited November 3, 2021 by Electrocutor Quote Link to comment Share on other sites More sharing options...
Delay Posted November 5, 2021 Share Posted November 5, 2021 I have found two more problems, one very minor, but I'd like to talk about it anyways (example patch below). Several parts with PartVariants (but not all of them) show up in the partslist in the SPH/VAB as pitch black, but they work and look fine in-game, so this isn't too concerning. What is a bit more concerning, however, is this: I mean, that looks hilarious, but that's a bit too engine (texture)-rich, even for KSP! All of these five parts use one single material (They are Ven's / Kerbas' revamped size 1 engines). For some reason, the Terrier and the Nerv use the main texture of the model for their particles. There are also other engines that show this behavior with their diffuse maps being used for particles, such as the aerospike. Unfortunately, I have yet to find any pattern to predict broken parts, so I cannot provide much of a direction here. I've run into this kind of issue before, where textures were applied even though the meshes should be disregarded. But (1.) that never happened with particles and (2.) if that was the case here, you would expect the Swivel and Reliant to be affected as well. Here are the important parts of the patches: Spoiler KSP_TEXTURE_SET { name = LVs MATERIAL { shader = TU/Metallic PROPERTY { name = _Metal float = 0.7 } excludeMesh = fairing excludeMesh = fairingL excludeMesh = fairingR excludeMesh = Size2A excludeMesh = Size2B texture = _MainTex, VenStockRevamp/Squad/Parts/Propulsion/JebEngines_CLR texture = _Emissive, VenStockRevamp/Squad/Parts/Propulsion/JebEngines_LUM textureColor = _BumpMap, 0.5, 0.5, 1.0, 0.5 texture = _MetallicGlossMap, TexturesUnlimited_VSR/Textures/Engines/LVs_SPC texture = _AOMap, TexturesUnlimited_VSR/Textures/Engines/LVs_SPC } //Fairing material { ... } //(Ven's part variants add shrouds to the engines. Different engines use different shrouds) //ShroudA material { mesh = Size2A ... } //ShroudB material { mesh = Size2B ... } //since only one of the above meshes is ever used per part (or not at all), I reckon this should be no problem } @PART[liquidEngine3]:FOR[TU_VSR]:NEEDS[VenStockRevamp] { MODULE { name = KSPTextureSwitch textureSet = LVs } } @PART[VenLV909b|liquidEngine3_v2|nuclearEngine]:FOR[TU_VSR]:NEEDS[VenStockRevamp] //These parts are affected... { @MODULE[ModulePartVariants] { @VARIANT,* { EXTRA_INFO { textureSet = LVs } } } MODULE { name = TUPartVariant } } //Reliant: @PART[liquidEngine|liquidEngine_v2]:FOR[TU_VSR]:NEEDS[VenStockRevamp] //...but the following two are not. { //They are only patched separately because I needed to @MODEL //replace their models with ones of older VSR releases, { //otherwise they would be completely black with TU. @model = TexturesUnlimited_VSR/Fixes/LVT30 } @MODULE[ModulePartVariants] { @VARIANT,* { EXTRA_INFO { textureSet = LVs } } } MODULE { name = TUPartVariant } } //Swivel: @PART[liquidEngine2|liquidEngine2_v2]:FOR[TU_VSR]:NEEDS[VenStockRevamp] { @MODEL { @model = TexturesUnlimited_VSR/Fixes/LVT45 } @MODULE[ModulePartVariants] { @VARIANT,* { EXTRA_INFO { textureSet = LVs } } } MODULE { name = TUPartVariant } } Incidentally, the size 1 engines are amongst those with first problem, too. Quote Link to comment Share on other sites More sharing options...
Electrocutor Posted November 22, 2021 Share Posted November 22, 2021 (edited) On 11/5/2021 at 5:44 PM, Delay said: I have found two more problems, one very minor, but I'd like to talk about it anyways (example patch below). Several parts with PartVariants (but not all of them) show up in the partslist in the SPH/VAB as pitch black, but they work and look fine in-game, so this isn't too concerning. What is a bit more concerning, however, is this: I mean, that looks hilarious, but that's a bit too engine (texture)-rich, even for KSP! All of these five parts use one single material (They are Ven's / Kerbas' revamped size 1 engines). For some reason, the Terrier and the Nerv use the main texture of the model for their particles. There are also other engines that show this behavior with their diffuse maps being used for particles, such as the aerospike. Unfortunately, I have yet to find any pattern to predict broken parts, so I cannot provide much of a direction here. I've run into this kind of issue before, where textures were applied even though the meshes should be disregarded. But (1.) that never happened with particles and (2.) if that was the case here, you would expect the Swivel and Reliant to be affected as well. Here are the important parts of the patches: Incidentally, the size 1 engines are amongst those with first problem, too. Firstly, remember that I said the PartVariant integration only got to an alpha release, so the mileage may vary. Secondly, it looks like you are trying to have all variants use the TU shader: the proper way to do that is to set the model itself to use TU via KSP_MODEL_SHADER instead of messing with whatever PartModules. The normal ModulePartVariants can change shader properties on the TU shader just fine, it just can't set the shader to TU, so if you set the shader via the model, the rest can be done using stock variants. This is also how you ensure TU plays nicely with other variant modules like B9PartSwitch and others. KSP_MODEL_SHADER { name = path/model MATERIAL { // mesh= or excludeMesh= shader = TU/Metallic keyword = TU_STOCK_SPEC } } Edited November 22, 2021 by Electrocutor Quote Link to comment Share on other sites More sharing options...
ksp player Posted November 24, 2021 Share Posted November 24, 2021 Even though I installed it, it doesn't look shiny, or reflects anything. I also installed it on CKAN. Quote Link to comment Share on other sites More sharing options...
Delay Posted November 24, 2021 Share Posted November 24, 2021 2 minutes ago, ksp player said: Even though I installed it, it doesn't look shiny, or reflects anything. I also installed it on CKAN. That is because you need configs. TU only provides the framework for PBR shading to work, but it doesn't affect any part by itself. Quote Link to comment Share on other sites More sharing options...
ksp player Posted November 24, 2021 Share Posted November 24, 2021 7 minutes ago, Delay said: That is because you need configs. What configs? Quote Link to comment Share on other sites More sharing options...
Delay Posted November 24, 2021 Share Posted November 24, 2021 4 minutes ago, ksp player said: What configs? Configs are basically separate files that tell TU what to do to each part. You can make them yourself, but some are already provided by other people. I'll assume that you do not use any mods affecting stock parts? Like VenStockRevamp or ReStock? Then the Textures Unlimited Recolor Depot might be what you're looking for. Quote Link to comment Share on other sites More sharing options...
ksp player Posted November 24, 2021 Share Posted November 24, 2021 (edited) 7 hours ago, Delay said: I'll assume that you do not use any mods affecting stock parts? Like VenStockRevamp or ReStock? No, no, I don't use those mods. But what configs do I use? I have no experience at making configs at all. Edit: I figured it out, it was just my settings. Edited November 24, 2021 by ksp player Quote Link to comment Share on other sites More sharing options...
Gordon Dry Posted November 26, 2021 Share Posted November 26, 2021 (edited) Is it possible to preset/change the default values of BloomIntensity, BloomRad etc. of TexturesUnlimitedFX? Edit: On 2/19/2019 at 4:10 AM, Shadowmage said: LoL, ooops those are WIP/testing mods, that get compiled with TU (but that I forgot to remove from the package). Is this still a thing? That would mean those mods are in the packade by accident? Edited November 26, 2021 by Gordon Dry Quote Link to comment Share on other sites More sharing options...
Gwilides Posted November 27, 2021 Share Posted November 27, 2021 Hi guys, I recently installed this mod and noticed some small artifacts. Can you please tell me how to fix this? When moving the camera away from the rocket, sometimes some modules become covered with dark pimples. I guess it's about normal maps, right? Also the same texture appears on some types of tanks. I hope you can help me) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.