Jimbodiah Posted January 20, 2018 Share Posted January 20, 2018 Space is black, so it reflects black. In the VAB you have omni-directional lighting with lots of objects that are reflected and it all looks very cool, but in space there is nothing to reflect so you only see black. You may also be using the wrong values giving too much specular/reflection. Quote Link to comment Share on other sites More sharing options...
Cheesecake Posted January 20, 2018 Share Posted January 20, 2018 (edited) 30 minutes ago, Jimbodiah said: Space is black, so it reflects black. In the VAB you have omni-directional lighting with lots of objects that are reflected and it all looks very cool, but in space there is nothing to reflect so you only see black. You may also be using the wrong values giving too much specular/reflection. That`s right but the Kerbol is shining so there is light. The SSTU-Parts have correct reflections and are not so dark. For NSS-Octosat I used Mecripps config: Spoiler KSP_MODEL_SHADER { name = NSS_Parts model = NSS/Parts/OctoSat_Com_Core model = NSS/Parts/OctoSat_Com_HalfTop model = NSS/Parts/OctoSat_Com_Side model = NSS/Parts/OctoSat_Com_Core model = NSS/Parts/OctoSat_St_HalfTop model = NSS/Parts/OctoSat_Con_RCS model = NSS/Parts/OctoSat_Con_RCS2 model = NSS/Parts/OctoSat_Con_RCS3 model = NSS/Parts/OctoSat_Con_RW model = NSS/Parts/OctoSat_Pr_Ion model = NSS/Parts/OctoSat_Pr_LfOx model = NSS/Parts/OctoSat_Pr_Mp model = NSS/Parts/OctoSat_Pr_Nuclear model = NSS/Parts/OctoSat_Sc_Goo model = NSS/Parts/OctoSat_Sc_M900 model = NSS/Parts/OctoSat_Sc_MaterialBay model = NSS/Parts/OctoSat_Sc_Science model = NSS/Parts/OctoSat_Sc_SideDish model = NSS/Parts/OctoSat_Sc_TopDish model = NSS/Parts/OctoSat_St_Adapter model = NSS/Parts/OctoSat_St_Cargo model = NSS/Parts/OctoSat_St_CargoModule model = NSS/Parts/OctoSat_St_Decoupler model = NSS/Parts/OctoSat_St_HalfBottom model = NSS/Parts/OctoSat_St_HalfTop model = NSS/Parts/OctoSat_St_Plate model = NSS/Parts/OctoSat_St_Separator model = NSS/Parts/OctoSat_St_Side model = NSS/Parts/OctoSat_Ta_Side model = NSS/Parts/OctoSat_Ut_Battery model = NSS/Parts/OctoSat_Ut_FuelCell model = NSS/Parts/OctoSat_Ut_RTG model = NSS/Parts/OctoSat_Ut_SolarPanels TEXTURE // Metal { shader = SSTU/PBR/Metallic texture = _MetallicGlossMap,TexturesUnlimited_NSS/Textures/silver } } REFLECTION_CONFIG[default] { %enabled = true %interval = 1 } KSP_MODEL_SHADER { model = NSS/Parts/OctoSat_Ut_SolarPanels TEXTURE { shader = SSTU/PBR/StockMetallicBumped mesh = panel1 mesh = panel1a mesh = panel1a001 mesh = panel1a002 mesh = panel1a003 mesh = panel1a004 mesh = panel1a005 mesh = panel1a006 mesh = panel1a007 mesh = panel1a008 mesh = panel1a009 mesh = panel1a010 mesh = panel1a011 mesh = panel1a012 mesh = panel1a013 mesh = panel002 mesh = panel003 mesh = panel004 mesh = panel005 mesh = panel006 mesh = panel007 PROPERTY { name = _Metal float = 0.0 } } } And for the Shuttle I used: Spoiler @REFLECTION_CONFIG[default] { %enabled = true %interval = 1 } KSP_MODEL_SHADER { model = SPACE_SHUTTLE_SYSTEM/CREW TEXTURE { shader = SSTU/PBR/StockMetallicBumped mesh = WINDOWS2 PROPERTY { name = _Metal float = 0.0 } } } KSP_MODEL_SHADER { model = SPACE_SHUTTLE_SYSTEM/FUSELASE_AND_DOOR TEXTURE { shader = SSTU/PBR/StockMetallicBumped mesh = STBD_PLB_RADIATOR_1 mesh = STBD_PLB_RADIATOR_2 mesh = STBD_PLB_RADIATOR_3 mesh = STBD_PLB_RADIATOR_4 mesh = PORT_PLB_RADIATOR_1 mesh = PORT_PLB_RADIATOR_2 mesh = PORT_PLB_RADIATOR_3 mesh = PORT_PLB_RADIATOR_4 PROPERTY { name = _Metal float = 0.0 } } } It`s only a replacement for TR/TRR. Anything is wrong but I don`t know what. Edited January 20, 2018 by Cheesecake Quote Link to comment Share on other sites More sharing options...
Guest Posted January 20, 2018 Share Posted January 20, 2018 Ok so I have 1.3.1 and they look great! but how do you get 100% reflection from the parts? Quote Link to comment Share on other sites More sharing options...
Manwith Noname Posted January 21, 2018 Share Posted January 21, 2018 (edited) @dundun93 Depending on the configs you are running, reflection is disabled by default in the textures unlimited download from memory. Saying that, most of the configs I've seen around turn it on, so if you're seeing shiny parts that were otherwise quite bland in stock, reflections probably are on. Now, as has kind of been discussed above, reflection is a "by product" of the specular value so, if you have parts that allow you to open up the recolour gui in the editor, you can play with the specular slider for the selected "layer" there. Like I said in another thread...sometimes you need to think inside the box. If you can't access the gui menu because the configs don't make use of recolouring, then you'll need to edit configs manually. Edited January 21, 2018 by Manwith Noname Quote Link to comment Share on other sites More sharing options...
Cheesecake Posted January 21, 2018 Share Posted January 21, 2018 Here are some more pictures of my issue in contrast to a SSTU-tank. https://imgur.com/a/3AMnC The Octosat-parts are dark while the SSTU-tank is shiny. The Octosat-Parts only reflects the light of Kerbin but not the light of the Sun. Quote Link to comment Share on other sites More sharing options...
Jimbodiah Posted January 21, 2018 Share Posted January 21, 2018 (edited) Sstu uses actual pbr shaders and requires the additional pbr sstu extention to be truly mirror like reflective. TheTU config files for stock parts can only do so much with what is present in the stock part. Btw setting specular and metallic to very high values means it will look almost black in space. Check the NF Propulsion patch, as Electrocuter does some extra work to make the textures a little brighter vs the stock value with plain metalluc effect added. Edited January 21, 2018 by Jimbodiah Quote Link to comment Share on other sites More sharing options...
Shadowmage Posted January 21, 2018 Author Share Posted January 21, 2018 Updated release is available: https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.0.0.8 Minor maintenance update - fixes issues with symmetry part handling with the KSPTextureSwitch module. Quote Link to comment Share on other sites More sharing options...
akron Posted February 2, 2018 Share Posted February 2, 2018 (edited) Is there a syntax for targeting multiple meshes with KSPTextureSwitch? Something like: "transformName = mesh1, mesh2, mesh3"? Sorry if I am missing it, I am just trying to find a workaround for a particularly odd part with multiple pieces which are separate due to animations and mesh switching. Nothing I've tried works, and it may just not be the intended use/not implemented EDIT: If I give all meshes the same name, it works, but breaks other things. Just trying to find the best way Edited February 2, 2018 by akron Quote Link to comment Share on other sites More sharing options...
Jimbodiah Posted February 2, 2018 Share Posted February 2, 2018 So a new update to Probes+ with TU is imminent? Quote Link to comment Share on other sites More sharing options...
Manwith Noname Posted February 2, 2018 Share Posted February 2, 2018 @akron The way I have approached this, or at least what I think is your issue, is by defining multiple TEXTURE nodes in a texture set. So something like this... Spoiler KSP_TEXTURE_SET { name = name of set title = title to appear in texture switch bar recolorable = true or false TEXTURE { shader = shader you want to apply mesh = meshes you want to include excludeMesh = meshes you want to exclude PROPERTY { Any property you want to define } } TEXTURE { shader = shader you want to apply mesh = meshes you want to include excludeMesh = meshes you want to exclude PROPERTY { Any property you want to define } } TEXTURE { shader = shader you want to apply mesh = meshes you want to include excludeMesh = meshes you want to exclude PROPERTY { Any property you want to define } } } If you want more control, so each mesh group has it's own texture switch group, download my stock recolour config and mask pack (there's a link in Electrocutor's thread) and look at things like landing gear and wheels. There may be better ways to do it but....I'm a trial and error / break and fix kinda guy so I just mucked about until something stuck the way I wanted. Quote Link to comment Share on other sites More sharing options...
akron Posted February 2, 2018 Share Posted February 2, 2018 (edited) 22 minutes ago, Manwith Noname said: @akron The way I have approached this, or at least what I think is your issue, is by defining multiple TEXTURE nodes in a texture set Well, the problem is that the Texture switch module defines the mesh, not the Texture set. Like this @PART[meridiani]:FOR[CoatlAerospace]:NEEDS[TexturesUnlimited] { MODULE { //standard module name name = KSPTextureSwitch //this is the root transform from which the texture set will be applied; allows for models to use multiple texture-switch modules transformName = panels //for recolorable texture sets, this is the name that will be displayed for the 'section' in the GUI sectionName = Panel Color TEXTURESET { name = Gold } TEXTURESET { name = CF } TEXTURESET { name = GoldFoil } TEXTURESET { name = Thermal } TEXTURESET { name = Coatl } TEXTURESET { name = Silver } TEXTURESET { name = GoldFoil2 } } } I can try it, but it means that I have to set all new Texture sets just for the one part because they won't work on other parts. Am I following your thoughts? Or did I confuse myself? EDIT: What I want to avoid is creating a texture switch entry for each unique mesh name because it will duplicate the buttons on the right click menu for each one. Edited February 2, 2018 by akron Quote Link to comment Share on other sites More sharing options...
Shadowmage Posted February 2, 2018 Author Share Posted February 2, 2018 5 minutes ago, akron said: Well, the problem is that the Texture switch module defines the mesh, not the Texture set. Like this Actually, both... If you omit the 'transformName' from the TextureSwitch module, it will operate on the root 'model' transform from the part (and thus should grab all sub-meshes). Use of the 'modelTransform=' in the TextureSwitch module should be used in cases where you have multiple texture-switch modules present that intend to target specific transforms/meshes. For your use, a single textureswitch module (or no modules, using the default-shader-replacement setup), you can define multiple TEXTURE and mesh= nodes within each TEXTURE_SET (as in the example posted by @Manwith Noname ). Each texture-set can define what meshes it effects -- it is this ability that allows for complex models to still have texture-switching applied to them. Sounds like most of your problems are likely stemming from the 'transformName=' in your texture-switch module. Try just removing that line and see if the rest of the texture switch setup works. You might not need to specify explicit meshes; should only be needed if they use different textures within a single 'texture set', or you are using multiple texture-switch modules. Quote Link to comment Share on other sites More sharing options...
akron Posted February 2, 2018 Share Posted February 2, 2018 13 minutes ago, Shadowmage said: Sounds like most of your problems are likely stemming from the 'transformName=' in your texture-switch module. Try just removing that line and see if the rest of the texture switch setup works. You might not need to specify explicit meshes; should only be needed if they use different textures within a single 'texture set', or you are using multiple texture-switch modules. Cool, thank you for clarifying. I am actually using the texture switching explicitly on the foil textures on my parts (With a few exceptions), which means that I do need to somehow exclude the non-foil meshes within the part. Mainly because I could not get it working with specular maps already included in the DDS files, but that's a fight for another day. I'm very happy with it so far. Since I do use a generic set shared by all the parts, it does sound Like I'll need a special set just for the magnetometer. With each texture declaration within that set targeting each "foil" mesh, which I think there are 4 of them. So in total about 6 new texture sets, each with 4 texture definitions, each applied to one mesh. Quote Link to comment Share on other sites More sharing options...
Manwith Noname Posted February 2, 2018 Share Posted February 2, 2018 29 minutes ago, akron said: EDIT: What I want to avoid is creating a texture switch entry for each unique mesh name because it will duplicate the buttons on the right click menu for each one. Right, so, if the texture set is being applied to all meshes, then simply don't define the transform as mentioned above. You won't even need to define or exclude meshes in the texture set if it's a "blanket" cover. However, if you want to get creative and break things down in to mesh groups with texture switching for each group, you will need to create a specific texture set but there's a way to do this quite easily. You already have your texture set defined somehwere, so you copy it and rename it specific to the part, then add the extra detail required. To save you downloading the stock recolour pack, here's the stock landing gear code...warning....it's quite long. Spoiler @PART[*]:FOR[zzzz_Something_after_P_because_2]:HAS[!MODULE[KSPTextureSwitch]]:HAS[#author[*Porkjet*]&@MODEL:HAS[#model[Squad/Parts/Wheel/LandingGear/*]]] { MODULE { name = KSPTextureSwitch sectionName = Body currentTextureSet = PorkjetStock_Default_Landing_Gear TEXTURESET { name = PorkjetStock_Default_Landing_Gear } TEXTURESET { name = PorkjetStock_DefaultMetal_Landing_Gear } TEXTURESET { name = PorkjetStock_Metal_Landing_Gear } TEXTURESET { name = MWNN_Stock_Tint_Landing_Gear } } MODULE { name = KSPTextureSwitch sectionName = Struts currentTextureSet = PorkjetStock_Default_Landing_Gear_Struts TEXTURESET { name = PorkjetStock_Default_Landing_Gear_Struts } TEXTURESET { name = PorkjetStock_DefaultMetal_Landing_Gear_Struts } TEXTURESET { name = PorkjetStock_Metal_Landing_Gear_Struts } TEXTURESET { name = MWNN_Stock_Tint_Landing_Gear_Struts } } MODULE { name = KSPTextureSwitch sectionName = Wheel currentTextureSet = PorkjetStock_Default_Landing_Gear_Wheel TEXTURESET { name = PorkjetStock_Default_Landing_Gear_Wheel } TEXTURESET { name = PorkjetStock_DefaultMetal_Landing_Gear_Wheel } TEXTURESET { name = PorkjetStock_Metal_Landing_Gear_Wheel } TEXTURESET { name = MWNN_Stock_Tint_Landing_Gear_Wheel } } } +KSP_TEXTURE_SET[PorkjetStock_Default] { @name = PorkjetStock_Default_Landing_Gear @TEXTURE { mesh = Base mesh = BayDoor1 mesh = BayDoor2 excludeMesh = WheelRetract excludeMesh = Damper excludeMesh = link excludeMesh = PistonExtend excludeMesh = Mesh excludeMesh = rod excludeMesh = prong excludeMesh = WheelBogey excludeMesh = wheel excludeMesh = wheel 7 excludeMesh = wheel 8 excludeMesh = w1 excludeMesh = w2 excludeMesh = w3 excludeMesh = w4 excludeMesh = w5 excludeMesh = w6 excludeMesh = Lamp excludeMesh = BrakeIndicator } } +KSP_TEXTURE_SET[PorkjetStock_DefaultMetal] { @name = PorkjetStock_DefaultMetal_Landing_Gear @TEXTURE { mesh = Base mesh = BayDoor1 mesh = BayDoor2 excludeMesh = WheelRetract excludeMesh = Damper excludeMesh = link excludeMesh = PistonExtend excludeMesh = Mesh excludeMesh = rod excludeMesh = prong excludeMesh = WheelBogey excludeMesh = wheel excludeMesh = wheel 7 excludeMesh = wheel 8 excludeMesh = w1 excludeMesh = w2 excludeMesh = w3 excludeMesh = w4 excludeMesh = w5 excludeMesh = w6 excludeMesh = Lamp excludeMesh = BrakeIndicator } } +KSP_TEXTURE_SET[PorkjetStock_Metal] { @name = PorkjetStock_Metal_Landing_Gear @TEXTURE { mesh = Base mesh = BayDoor1 mesh = BayDoor2 excludeMesh = WheelRetract excludeMesh = Damper excludeMesh = link excludeMesh = PistonExtend excludeMesh = Mesh excludeMesh = rod excludeMesh = prong excludeMesh = WheelBogey excludeMesh = wheel excludeMesh = wheel 7 excludeMesh = wheel 8 excludeMesh = w1 excludeMesh = w2 excludeMesh = w3 excludeMesh = w4 excludeMesh = w5 excludeMesh = w6 excludeMesh = Lamp excludeMesh = BrakeIndicator } } +KSP_TEXTURE_SET[MWNN_Stock_Tint] { @name = MWNN_Stock_Tint_Landing_Gear @TEXTURE { mesh = Base mesh = BayDoor1 mesh = BayDoor2 excludeMesh = WheelRetract excludeMesh = Damper excludeMesh = link excludeMesh = PistonExtend excludeMesh = Mesh excludeMesh = rod excludeMesh = prong excludeMesh = WheelBogey excludeMesh = wheel excludeMesh = wheel 7 excludeMesh = wheel 8 excludeMesh = w1 excludeMesh = w2 excludeMesh = w3 excludeMesh = w4 excludeMesh = w5 excludeMesh = w6 excludeMesh = Lamp excludeMesh = BrakeIndicator texture = _SpecMap,Squad/Parts/Wheel/LandingGear/LandingGear texture = _MaskTex,TU_Stock_Recolour/Wheel/Landing Gear/131_LandingGear_Paint } } +KSP_TEXTURE_SET[PorkjetStock_Default] { @name = PorkjetStock_Default_Landing_Gear_Struts @TEXTURE { mesh = WheelRetract mesh = Damper mesh = link mesh = PistonExtend mesh = Mesh mesh = rod mesh = prong mesh = WheelBogey excludeMesh = Base excludeMesh = BayDoor1 excludeMesh = BayDoor2 excludeMesh = wheel excludeMesh = wheel 7 excludeMesh = wheel 8 excludeMesh = w1 excludeMesh = w2 excludeMesh = w3 excludeMesh = w4 excludeMesh = w5 excludeMesh = w6 excludeMesh = Lamp excludeMesh = BrakeIndicator } } +KSP_TEXTURE_SET[PorkjetStock_DefaultMetal] { @name = PorkjetStock_DefaultMetal_Landing_Gear_Struts @TEXTURE { mesh = WheelRetract mesh = Damper mesh = link mesh = PistonExtend mesh = Mesh mesh = rod mesh = prong mesh = WheelBogey excludeMesh = Base excludeMesh = BayDoor1 excludeMesh = BayDoor2 excludeMesh = wheel excludeMesh = wheel 7 excludeMesh = wheel 8 excludeMesh = w1 excludeMesh = w2 excludeMesh = w3 excludeMesh = w4 excludeMesh = w5 excludeMesh = w6 excludeMesh = Lamp excludeMesh = BrakeIndicator } } +KSP_TEXTURE_SET[PorkjetStock_Metal] { @name = PorkjetStock_Metal_Landing_Gear_Struts @TEXTURE { mesh = WheelRetract mesh = Damper mesh = link mesh = PistonExtend mesh = Mesh mesh = rod mesh = prong mesh = WheelBogey excludeMesh = Base excludeMesh = BayDoor1 excludeMesh = BayDoor2 excludeMesh = wheel excludeMesh = wheel 7 excludeMesh = wheel 8 excludeMesh = w1 excludeMesh = w2 excludeMesh = w3 excludeMesh = w4 excludeMesh = w5 excludeMesh = w6 excludeMesh = Lamp excludeMesh = BrakeIndicator } } +KSP_TEXTURE_SET[MWNN_Stock_Tint] { @name = MWNN_Stock_Tint_Landing_Gear_Struts @TEXTURE { mesh = WheelRetract mesh = Damper mesh = link mesh = PistonExtend mesh = Mesh mesh = rod mesh = prong mesh = WheelBogey excludeMesh = Base excludeMesh = BayDoor1 excludeMesh = BayDoor2 excludeMesh = wheel excludeMesh = wheel 7 excludeMesh = wheel 8 excludeMesh = w1 excludeMesh = w2 excludeMesh = w3 excludeMesh = w4 excludeMesh = w5 excludeMesh = w6 excludeMesh = Lamp excludeMesh = BrakeIndicator texture = _SpecMap,Squad/Parts/Wheel/LandingGear/LandingGear texture = _MaskTex,TU_Stock_Recolour/Wheel/Landing Gear/131_LandingGear_Paint } } +KSP_TEXTURE_SET[PorkjetStock_Default] { @name = PorkjetStock_Default_Landing_Gear_Wheel @TEXTURE { excludeMesh = WheelRetract excludeMesh = Damper excludeMesh = link excludeMesh = PistonExtend excludeMesh = Mesh excludeMesh = rod excludeMesh = prong excludeMesh = WheelBogey excludeMesh = Base excludeMesh = BayDoor1 excludeMesh = BayDoor2 mesh = wheel mesh = wheel 7 mesh = wheel 8 mesh = w1 mesh = w2 mesh = w3 mesh = w4 mesh = w5 mesh = w6 excludeMesh = Lamp excludeMesh = BrakeIndicator } } +KSP_TEXTURE_SET[PorkjetStock_DefaultMetal] { @name = PorkjetStock_DefaultMetal_Landing_Gear_Wheel @TEXTURE { excludeMesh = WheelRetract excludeMesh = Damper excludeMesh = link excludeMesh = PistonExtend excludeMesh = Mesh excludeMesh = rod excludeMesh = prong excludeMesh = WheelBogey excludeMesh = Base excludeMesh = BayDoor1 excludeMesh = BayDoor2 mesh = wheel mesh = wheel 7 mesh = wheel 8 mesh = w1 mesh = w2 mesh = w3 mesh = w4 mesh = w5 mesh = w6 excludeMesh = Lamp excludeMesh = BrakeIndicator } } +KSP_TEXTURE_SET[PorkjetStock_Metal] { @name = PorkjetStock_Metal_Landing_Gear_Wheel @TEXTURE { excludeMesh = WheelRetract excludeMesh = Damper excludeMesh = link excludeMesh = PistonExtend excludeMesh = Mesh excludeMesh = rod excludeMesh = prong excludeMesh = WheelBogey excludeMesh = Base excludeMesh = BayDoor1 excludeMesh = BayDoor2 mesh = wheel mesh = wheel 7 mesh = wheel 8 mesh = w1 mesh = w2 mesh = w3 mesh = w4 mesh = w5 mesh = w6 excludeMesh = Lamp excludeMesh = BrakeIndicator } } +KSP_TEXTURE_SET[MWNN_Stock_Tint] { @name = MWNN_Stock_Tint_Landing_Gear_Wheel @TEXTURE { excludeMesh = WheelRetract excludeMesh = Damper excludeMesh = link excludeMesh = PistonExtend excludeMesh = Mesh excludeMesh = rod excludeMesh = prong excludeMesh = WheelBogey excludeMesh = Base excludeMesh = BayDoor1 excludeMesh = BayDoor2 mesh = wheel mesh = wheel 7 mesh = wheel 8 mesh = w1 mesh = w2 mesh = w3 mesh = w4 mesh = w5 mesh = w6 excludeMesh = Lamp excludeMesh = BrakeIndicator texture = _SpecMap,Squad/Parts/Wheel/LandingGear/LandingGear texture = _MaskTex,TU_Stock_Recolour/Wheel/Landing Gear/131_LandingGear_Paint } } Quote Link to comment Share on other sites More sharing options...
akron Posted February 2, 2018 Share Posted February 2, 2018 (edited) 17 minutes ago, Manwith Noname said: To save you downloading the stock recolour pack, here's the stock landing gear code...warning....it's quite long. Boom. I just spotted what I needed. I can define multiple meshes in the Texture set, one by line. I just need to move those 4 and, like you said, copy the sets from the other parts. It will still be a unique Texture switch for just the part, but that's just because it is the only one that has its "foil" meshes with different names. To be clear, I do not use textures the traditional way, some of my parts can have up to 4 materials assigned to different meshes. Mostly to get texture switching to work. Initially with Firespitter, and now additionally with TU. Thank you @Manwith Noname! EDIT: I could combine the texture switching modules, but I'd have to go back through all the parts that would use and make sure they have the same naming convention. It'll just be more work, but I now understand how to do it Edited February 2, 2018 by akron Quote Link to comment Share on other sites More sharing options...
Manwith Noname Posted February 2, 2018 Share Posted February 2, 2018 49 minutes ago, akron said: EDIT: I could combine the texture switching modules, but I'd have to go back through all the parts that would use and make sure they have the same naming convention. It'll just be more work, but I now understand how to do it If it ain't broke, don't try to fix it ;D Quote Link to comment Share on other sites More sharing options...
popos1 Posted February 3, 2018 Share Posted February 3, 2018 Hi, one question: there is a config to stock parts? Quote Link to comment Share on other sites More sharing options...
Shadowmage Posted February 3, 2018 Author Share Posted February 3, 2018 2 hours ago, popos1 said: Hi, one question: there is a config to stock parts? Electrocutor's thread has some patches that apply these shaders for stock parts (and several other mods as well) -- Quote Link to comment Share on other sites More sharing options...
Electrocutor Posted February 3, 2018 Share Posted February 3, 2018 (edited) On 2/2/2018 at 9:22 AM, akron said: Mainly because I could not get it working with specular maps already included in the DDS files, but that's a fight for another day. shader = SSTU/PBR/StockMetallicBumped This uses the pre-existing specular alpha layer from a dds and uses it for reflective specularity. For SSTU/PBR/Metallic, the specular map is set via: texture = _MetallicGlossMap,<path excluding .dds> ; specular on alpha, metallic on red. Edited February 3, 2018 by Electrocutor Quote Link to comment Share on other sites More sharing options...
Jimbodiah Posted February 3, 2018 Share Posted February 3, 2018 Electro should put a link in his signature to promote his patches Quote Link to comment Share on other sites More sharing options...
Electrocutor Posted February 3, 2018 Share Posted February 3, 2018 39 minutes ago, Jimbodiah said: Electro should put a link in his signature to promote his patches For stock parts, I believe ManWithNoName is quite a ways ahead of myself; but I think he doesn't believe that he's reached a "release-worthy" point yet to create his own thread. Quote Link to comment Share on other sites More sharing options...
Manwith Noname Posted February 7, 2018 Share Posted February 7, 2018 There's an element of that for sure but other reasons too. For starters, I kind of see the overhaul of stock as more of a community effort rather than one individual. I've got plenty of experience with making masks and can do that pretty quick (cut OPT over the weekend). Not so much making AO and bump maps, though I have been goofing about with bumps to begin understanding them. The framework is there to be expanded further. It just needs the extra textures (bumps and what not) along with some "balancing" and tidying up. Which leads me to why I have slowed down work on the stock overhaul...KSP 1.4 is due "soon". Given the features that are coming I suspect there may well be a certain amount of an overhaul with what already comes in the game so I wouldn't want to spend the time making bump maps where they are missing (which is the majority of parts) only to then find the game now has files that are usable in that aspect. Masks may also need to be redone or added to depending on what is coming. I've also been reading the TU github code and wiki to find out certain things and stumbled upon certain changes which are due to take place with the mod itself. It appears the plan is to remove the current masked PBR shader in lieu of something else rather than them being able to run side by side. At this stage, I'm not entirely sure there will be a quick fix to get things back up and running after the update as it seems there will be a hardcoded requirement for another texture which would need creating. RGB masks will always be useful I suspect so I'm more focused on creating those for mods I had always planned to cover in KerbPaint. The main reason I had considered making a thread at all was to allow for easier updating of the link. Not sure I want to keep finding old posts and updating them...so maybe I'll make a thread anyway...."soon". Quote Link to comment Share on other sites More sharing options...
HaArLiNsH Posted February 7, 2018 Share Posted February 7, 2018 (edited) Hey @Shadowmage I've just discovered this mod and I must say it look really impressive I'm seriously thinking about making a big rewrite of TRR, more focused on the kerbal side and I've some question about TU, especially because we have big difficulties with the shader for our reflections. - Is the actual version of TRR (5.4) working with TU or does it make conflict ? If yes, where ? - Does it work on our kerbals or only on vessel part ? - Are the reflections "real" or is it just the environment ? I mean , in TRR, we make another camera view at each refresh interval and we create an image and this image is projected on the surface we want the reflection. This way we can see our kerbal and crafts in real time but as you know, this is not really good for the performance. Edited February 7, 2018 by HaArLiNsH spelling Quote Link to comment Share on other sites More sharing options...
Shadowmage Posted February 7, 2018 Author Share Posted February 7, 2018 1 hour ago, HaArLiNsH said: Is the actual version of TRR (5.4) working with TU or does it make conflict ? If yes, where ? I have no idea; I've never used TRR personally (generally too busy modding things ). There have been some reports of conflicts, but I've not much info beyond that, and I believe the conflicts were resolved by turning of TRR reflection handling on parts/vessels (which makes sense why there would be conflicts there). 1 hour ago, HaArLiNsH said: Does it work on our kerbals or only on vessel part ? Currently only on parts. In theory you could apply the shaders to any mesh/skinned-mesh renderer component (anything with a Material). My focus was on getting environment reflections working on vessels, as I felt that is where the biggest return on investment would be found (performance impact and development time). I originally had some plans to add support for Kerbals (including texture-switching for suits), but honestly I didn't want to trample all over TRR's feature set. 1 hour ago, HaArLiNsH said: Are the reflections "real" or is it just the environment ? They are as real as the reflections in TRR (but they don't capture kerbals or vessels) . In fact the cubemap rendering is based loosely on TR/TRR code (originally anyway, it has since evolved to its own beast). The main difference is that I then take the cube-map that I've rendered, and slap it into a Unity Reflection Probe which convolves image for use as a specular reflection (blurs the mip-map levels), which then gets used by the shaders. 1 hour ago, HaArLiNsH said: , this is not really good for the performance. This is specifically why I -don't- capture Kerbals or vessels in the reflection map. The performance hit for looping through the parts is too big, especially when trying to setup a cubemap -per part-. Even updating just a single 'environment' cubemap is quite expensive due to how the updates need to be done (if I could use the Unity builtin Reflection Probe updating routines it would be faster, but those do not work with KSPs layered rendering). Well, capturing Kerbals in the reflections wouldn't be that hard/bad (as I think they are on their own layer?), but certainly the per-part-cubemap is a bit too much. In theory you could take the shaders and reflection probe handling from TU and use them in the existing TRR code/setup if you wanted to take advantage of the convoluted specular reflection. If you were interested, I would be willing for a bit of collaboration towards some synergy between the two mods. Something like TU handles the shaders and reflection rendering/setup, while TRR would focus on replacing of textures (kerbals, skyboxes, etc). In order to keep the entire feature-set of TRR it might be necessary to add an option to TU for vessel reflections (and kerbals). Not quite sure how this would work out, as you would need to somehow not capture the currently controlled vessel, while still capturing any -other- vessels in the scene. Something we can work out if there is interest (and need/desire). If this is something you are interested in, please let me know one way or another (reply here, PM, etc...). 1 hour ago, Manwith Noname said: I've also been reading the TU github code and wiki to find out certain things and stumbled upon certain changes which are due to take place with the mod itself. It appears the plan is to remove the current masked PBR shader in lieu of something else rather than them being able to run side by side. At this stage, I'm not entirely sure there will be a quick fix to get things back up and running after the update as it seems there will be a hardcoded requirement for another texture which would need creating. Plans were to remove that shader if I could find a working replacement. As I haven't been able to find/make anything better... it probably will be kept around (unfortunately). But it likely won't be getting any changes/updates either. The closest I've come was the 'HSV-mapped' dynamic recoloring that I was working on for a bit... but I really wasn't happy with the limitations of that method. It might still get developed a bit further, but I would need to find an easier/better way to handle the mask generation. Well, the back end functions worked perfectly, it was just the mask-generation that was a bit iffy. Sadly, kind of a step backwards though, as it only made the problem worse by requiring even more texture inputs (though the recoloring output was outstanding/close to perfect). (so the shader itself is great, it just requires additional texture inputs in order to recolor things properly and people already seem to struggle with even the concept of 'have to make more/new textures to use recoloring') Currently the biggest change coming to TU with the KSP 1.4 updates will likely be some changes to the config node setup/naming. Nothing that couldn't be fixed with a couple minutes with notepad++ and search/replace. Quote Link to comment Share on other sites More sharing options...
HaArLiNsH Posted February 7, 2018 Share Posted February 7, 2018 15 minutes ago, Shadowmage said: I have no idea; I've never used TRR personally (generally too busy modding things ). I have the same problem, the only "play" I do at KSP is learning by modding with TRR. And starting by this one is like jumping on a wild train 23 minutes ago, Shadowmage said: In theory you could take the shaders and reflection probe handling from TU and use them in the existing TRR code/setup if you wanted to take advantage of the convoluted specular reflection. If you were interested, I would be willing for a bit of collaboration towards some synergy between the two mods. Something like TU handles the shaders and reflection rendering/setup, while TRR would focus on replacing of textures (kerbals, skyboxes, etc). In order to keep the entire feature-set of TRR it might be necessary to add an option to TU for vessel reflections (and kerbals). Not quite sure how this would work out, as you would need to somehow not capture the currently controlled vessel, while still capturing any -other- vessels in the scene. Something we can work out if there is interest (and need/desire). If this is something you are interested in, please let me know one way or another (reply here, PM, etc...). I think this could be a great thing to do. TR/TRR are made of pile of features that were added with the time and as I said, I'm really considering a rewrite of TRR so it can be more modular and I will remove the obsolete/buggy stuff. The shader and reflection is not a part I totally control/understand yet and they are working with the help of @Ger_space and @ThirdOfSeven. And we still have issues with it because I know nearly nothing on this. So yes, I'm interested And I think @Avera9eJoe and his Windowshine would be too. I can take care of the textures and let you the shader/reflection part. Anyway something has to be done because our kind of mod need to be able to coexist and benefit from each other like EVE, scatterer, .. The more it goes, the more I'm interested in the customization of our kerbals and I'll be grateful if you can save me from the shader/reflection nightmare. I've open the body swapping Pandora's box and now I'm really focus on this. I can already tell you that a option to be able to choose if we want to reflect our kerbals and vessels (and be performance consuming) or not is definitively something that "need" to be looked at. Also, I don't know if this is in your domain, but I'm also interested in adding a glow layer on our kerbal so we could have suits with glowing part. This and why not a metallic shader could allow us to make wonderful and crazy suits I think we can discuss this in more detail in PM. 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.