shadowmage45 / texturesunlimited Goto Github PK

When using the Recolor GUI, it automatically sets all child parts to the same settings as the parent part that you currently have the GUI open for, even when the child part is just a stock part using the standard KSP shader and its own textures, it changes them all to match the parent.

When you actually change views (say launch), then it resets the child back to how it should be, so this is only a problem with GUI itself in the editor.

Add configurable options to KSPTextureSwitch that can automatically switch between TextureSets depending on conditions.

For example,
if (oVessel.geeForce > (oPart.gTolerance * 0.8))
{ SetTextureSet(glassCrack); }

On the SSTU/PBR/Metallic shader, could you add two properties '_Metallic' and '_Smoothness' as floats that default to 1.0 and are used as multiplier to the _MetallicGlossMap?

This would allow us to just use the default "white" _MetallicGlossMap alongside setting a specific metallicy and smoothness without needing to provide and load a single 1x1 pixel texture.

Example:

TEXTURE // gold
{
shader = SSTU/PBR/Metallic
texture = _MainTex,

PROPERTY
{
	name = _Color
	color = 1.0,0.84,0.0
}
PROPERTY
{
	name = _Metallic
	float = 0.8
}
PROPERTY
{
	name = _Smoothness
	float = 0.9
}

}
TEXTURE // silver
{
shader = SSTU/PBR/Metallic
texture = _MainTex,

PROPERTY
{
	name = _Color
	color = 0.75,0.75,0.75
}
PROPERTY
{
	name = _Metallic
	float = 0.8
}
PROPERTY
{
	name = _Smoothness
	float = 0.9
}

}

Example: USI's ORE_DRILL
MODEL
{
model = Squad/Parts/Resources/RadialDrill/TriBitDrill
texture = TriBitDrill, UmbraSpaceIndustries/KarbonitePlus/Assets/TriBitDrill_GY
scale = 2,2,2
}

The place the exception is being thrown is the KSP API: PartLoader.ReplaceTextures.

Suspect TU cfg:
model = Squad/Parts/Resources/RadialDrill/TriBitDrill
TEXTURE
{
shader = SSTU/PBR/Metallic

	texture = _MetallicGlossMap,TexturesUnlimited_Stock/Textures/silver

	excludeMesh = flagTransform
	excludeMesh = Flag
}

Looks like the reflections on the stock-patched parts point in the wrong (opposite) direction in at least some cases.

SSTU's parts' reflections all point in the proper direction, pointing towards this being related to specific meshes, normal-maps, or the shader itself.

Enhancement Request
Please, add a keyword like 'ALBEDOALPHA_INVERT' to the 'SSTU/PBR/StockMetallicBumped' shader. It seems that some of the smoothness values that are used by default in stock parts are exactly reverse from what they should be while others seem to be correct.

Use Shared Materials...

For each KSP_TEXTURE_SET, have it create shared materials instead of each being its own new instance.

They would need to switch from being a shared material to be an individual one if the Recolor GUI is clicked and any value is changed.

This will not make any difference in small craft; but makes a dramatic difference when having hundreds of the same part or parts that share the same material textures and properties.

It seems like the x,y for _Emission has a bug somewhere. In the following example, just turn on the lights for the pod, and you will see the rungs also light up, even though the rungs should be in the black part of the _Emission map. It may be the difference in size. Squad uses 1024x1024 for diffuse and normals most of the time, but 256x256 for emission.

KSP_MODEL_SHADER
{
name = StockSteel
model = Squad/Parts/Command/Mk1-2Pod/model

TEXTURE
{
	shader = SSTU/PBR/StockMetallicBumped
	mesh = rung
}

}

The Transparency Shader seems to not work quite right.

Scenario:
One mesh with two parts of it on top of each other. After the UV wrap, the outer part has some areas of 100% transparency and the inner part has 0% transparency. Instead of it being that way, instead the whole thing is just 50% transparent.

I'm adding a reference here to the exceptions that TU throws in v1.4. I'm not sure if these have been resolved, but the currently released version still contains them.

[ERR 19:17:03.520] Exception handling event OnPartLoaderLoaded in class TexturesUnlimitedLoader:System.NullReferenceException: Object reference not set to an instance of an object
at KSPShaderTools.TexturesUnlimitedLoader.applyToPartIcons () [0x00000] in :0
at KSPShaderTools.TexturesUnlimitedLoader.onPartListLoaded () [0x00000] in :0
at EventVoid.Fire () [0x00000] in :0

[EXC 19:17:03.522] NullReferenceException: Object reference not set to an instance of an object
KSPShaderTools.TexturesUnlimitedLoader.applyToPartIcons ()
KSPShaderTools.TexturesUnlimitedLoader.onPartListLoaded ()
EventVoid.Fire ()
UnityEngine.Debug:LogException(Exception)
EventVoid:Fire()
c__Iterator0:MoveNext()
UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

Apparently the skybox used in the editor is the -actual- Unity.RenderSettings.skybox. Who would have known?

https://github.com/Real-Gecko/LightsOut/blob/master/LightsOut/LOAmbient.cs#L31

Should be relatively simple to setup the reflection camera to allow it to capture the standard skybox.

When switching between TextureSets, values not specified do not return to default values.

Scenario:
KSP_TEXTURE_SET
{
name = Metal
title = Metal
recolorable = false

TEXTURE
{
	shader = SSTU/PBR/Metallic

	PROPERTY
	{
		name = _Metal
		float = 0.75
	}
	PROPERTY
	{
		name = _Smoothness
		float = 0.75
	}
}

}
KSP_TEXTURE_SET
{
name = RedMetal
title = RedMetal
recolorable = false

TEXTURE
{
	shader = SSTU/PBR/Metallic

	PROPERTY
	{
		name = _Color
		color = 1.0,0,0
	}
	PROPERTY
	{
		name = _Metal
		float = 0.75
	}
	PROPERTY
	{
		name = _Smoothness
		float = 0.75
	}
}

}

However, also remember that if there are multiple instances of KSPTextureSwitch, they may be cumulative. For example, one instance to set _Color and one to set _Metal and _Smoothness.

To comply with how default KSP shaders work, if a texture does not have an alpha layer enabled, then the default specular is 0% instead of 100%. Personally, I think 30% or 40% would make more sense.

Goal

• Allow for easier use of 'full color' textures.
• Notably these would be most often used when creating full single-color mask textures
• Could also be used for very basic 'GLOW' textures when only the single mesh uses the texture

Technical

• Use the already provided list of 'Preset Colors'
• Create a small static 2D texture at run-time (64x64 is the smallest that will work without MIP problems)
• When assigning textures, first check if the texture name is one of the available 'preset color' names
  • The only potential conflict this could run into is if someone were to also store a simply-named texture file in the GameData root directory -- e.g. GameData/red.png would clash with the 'red' preset color.
  • Under the proposed setup the texture would be ignored, and the color would be used.
• How to handle texture assignments that are intended to have an alpha channel component?
  • Could create multiple technical color preset defs that could be selected from
    • E.G technicalBlackNoAlpha(RGB=0, A=0) / technicalBlackFullAlpha (RGB=0, A=1)

ADDENDUM:

• Preset-color definitions will need to support a 'technicalOnly' flag value in their configs, which will hide the flagged color from the recoloring GUI. This is to allow for 'technical' colors to be added -- white, black, gray, NRM base, without them showing up on the recoloring GUI system.

Due to the problems of many of the texture setups requiring specific alpha channel specifications, the above setup will simply not be a viable solution (could be done, but would be extremely cludgy to deal with).

Instead, it should be made possible to specify a color value inside of the PARAMETER block used for textures. This would mean that 'color-texture-replacements' could not be done through the simple 'texture=XXX' syntax, but that is a small price to pay for a much cleaner interface.

Proposed config for color-texture-replacement config node:

KSP_TEXTURE_SET
{
    name = foo-bar
    TEXTURE
    {
        shader = fooShader
        PARAMETER
        {
            name = _MainTex
            textureColor = 255,0,0,255
        }
        PARAMETER
        {
            name = _BumpMap
            texture = SSTU/Assets/RandomNormalMap-NRM
            normal = true
        }
    }
}

From forum post: https://forum.kerbalspaceprogram.com/index.php?/topic/167450-131-textures-unlimited-pbr-shader-texture-and-model-api-11-11-17/&do=findComment&comment=3218459

KSP_MODEL_SHADER
{
	name = Mk1

	model = Squad/Parts/Command/mk1pod/model
	model = Squad/Parts/Command/mk1LanderCan/model
	model = Squad/Parts/Command/mk1Cockpits/CockpitStandard
	model = Squad/Parts/Command/mk1Cockpits/CockpitInline
	model = Squad/Parts/Command/mk1Cockpits/Cabin

	model = Squad/Parts/Structural/mk1Parts/StructuralHollow
	model = Squad/Parts/Structural/mk1Parts/Fuselage
	model = Squad/Parts/Structural/mk1Parts/IntakeFuselage
	model = Squad/Parts/Structural/mk1Parts/Nacelle1
	model = Squad/Parts/Structural/mk1Parts/Nacelle2

	model = Squad/Parts/Aero/cones/NCS
	model = Squad/Parts/Aero/airIntakeRadialXM-G50/RadialIntake
	model = Squad/Parts/Aero/circularIntake/CircularIntake
	model = Squad/Parts/Aero/circularIntake/ConeIntake
	model = Squad/Parts/Aero/ramAirIntake/RampIntake

	model = Squad/Parts/Engine/jetEngines/turboFanSize1
	model = Squad/Parts/Engine/jetEngines/turboJet
	model = Squad/Parts/Engine/jetEngines/turboRamJet

	model = Squad/Parts/Utility/dockingPortInline/model

	TEXTURE
	{
		shader = SSTU/PBR/StockMetallicBumped

		mesh = obj_base
		mesh = Cockpit
		mesh = Cabin

		mesh = StructuralHollow
		mesh = Fuselage
		mesh = IntakeFuselage
		mesh = Nacelle1
		mesh = Nacelle2

		mesh = Cone
		mesh = RadialIntake
		mesh = FanIntake
		mesh = ConeIntake
		mesh = RampIntake

		mesh = TurboFanSize1
		mesh = Reverser
		mesh = TurboJet
		mesh = TurboRamjet

		mesh = housing
		mesh = door1
		mesh = door2
		mesh = port

		mesh = window

		mesh = rung
	}
}

Build any craft out of Mk1 parts.
Time-warp to a bit past morning.
Roll around slowly and watch the lighting across the whole vessel as well as the brightness of reflections.

Create a specific shader intended solely for recoloring of existing stock/mod textures.

Current concept:

• Decompose current RGB into HSV
• Set H to value from recoloring GUI RGB selection
• S = ?
• V = ?

Unable to find a way to maintain color differential / minor hue differences. Can replace hue entirely while keeping S+V.

S +V are more problematic. You cannot simply set them to the value from the GUI, or the output will be a flat texture without any details. Without an additional texture-input that says what the 'base' S+V are for any pixel, no manipulation of this data can be done without discarding the existing texture information.

It really serves no purpose and causes you to have less room for your own description.

Experiencing violent explosions/disassembles when staging PF fairing. Works fine with stock fairings.
Attached, craft file to reproduce issue.

PF Test.zip

Console/log output:

[LOG 23:06:20.928] DragCubeSystem: Rendering procedural drag for KW2mFairingPFE
[LOG 23:06:20.970] DragCubeSystem: Rendering procedural drag for KzProcFairingSide4
[LOG 23:06:20.999] DragCubeSystem: Rendering procedural drag for KzProcFairingSide4
[LOG 23:06:22.631] 11/14/2017 11:06:22 PM,ShipManifest-DfWrapper,Attempting to Grab DeepFreeze Types...
[LOG 23:06:27.175] SSTUReflectionManager vesselCreated() : KzProcFairingSide4 (Vessel) :: KSPShaderTools.ReflectionManager+VesselReflectionData
[LOG 23:06:27.177] SSTUReflectionManager vesselCreated() : KzProcFairingSide4 (Vessel) :: KSPShaderTools.ReflectionManager+VesselReflectionData
[LOG 23:06:27.417] [F: 56999]: KWsrbGlobeVI collided into Launch Pad - relative velocity: 31.24613 - no impact momentum (no RB)
[LOG 23:06:27.418] KWsrbGlobeVI Exploded!! - blast awesomeness: 0.5
[LOG 23:06:27.420] [strutConnector]: Deactivated
[LOG 23:06:27.427] SSTUReflectionManager vesselCreated() : launchClamp1 (Vessel) :: KSPShaderTools.ReflectionManager+VesselReflectionData
[LOG 23:06:27.429] SSTUReflectionManager vesselCreated() : launchClamp1 (Vessel) :: KSPShaderTools.ReflectionManager+VesselReflectionData
[LOG 23:06:27.436] [KWsrbGlobeVI]: Deactivated
[LOG 23:06:27.466] 1 explosions created.
[LOG 23:06:27.567] Flight State Captured
[LOG 23:06:27.567] Saving Achievements Tree...
[LOG 23:06:27.568] Saving Achievements Tree...
[LOG 23:06:27.569] [MessageSystem] Save Messages
[LOG 23:06:27.678] Game State Saved to saves/ISS/persistent
[LOG 23:06:31.206] Packing Dream Chaser Cargo Debris for orbit
[LOG 23:06:31.230] Unpacking Dream Chaser Cargo Debris
[WRN 23:06:38.834] [F: 57387]: Vessel Dream Chaser Cargo Debris crashed through terrain on Kerbin.
[LOG 23:06:38.836] KzProcFairingSide4 Exploded!! - blast awesomeness: 0.5
[LOG 23:06:38.837] [KzProcFairingSide4]: Deactivated 

There duplicate fields in the KSPTextureSwitch module:
allowInFlightChange
canChangeInFlight

Could you please allow the _Color alpha channel to act as multiplier for the Smoothness property instead of just _MainTex alpha?

The case is when a _MainTex is not specified, thus you could simply have the material be a color and normal; for example gold foil.

It seems that at some times, the reflection directions can become out of synch with reality. Also, the atmosphere reflection from kerbin will often follow all the way to the Mun.

A trip to the space center and back to the craft fixes these problems.

So far have been unable to duplicate it in specific testing, though the issue was occuring regularly during my 'play' time.

--- very well could be related to actual launches / travel through the atmosphere. The dedicated tests have all been using the stock set-orbit tool, and using this no problems can be seen.

If viable, should be able to give much higher brightness to 'lights' captured and brightly lit objects captured by the reflection probe camera.

• No clue if HDR needs to be enabled through the entire render pathway or not (e.g. on all shaders, cameras). Will enabling HDR capture actually do anything different than the current capture?
• Do the existing shader variants support HDR?

Nomnom, tasty shading...

https://docs.unity3d.com/Manual/StandardShaderMaterialParameterHeightMap.html

Might be overkill for the current uses, but still likely a few models that could take advantage of it if it were available.

TU 2.0 / KSP 1.4 Updates

Proposed changes/updates for upcoming TU major version update. Tentatively scheduled to be released alongside the update to KSP 1.4. No actual ETA.

• Change in included shaders.
• Shader-aware material handling
• Single texture-switch module for any mesh
• PresetColor multi-defs
• Support optional wholesale texture replacement
• Support optional wholesale shader replacement
• Texture Set Parameter Shorthand
• Keyword support for shaders.
• (Bonus) 'Slotted' texture-switch module support + configs. (if dev time permits, and I can figure out a clean implementation)

List of shaders

• TU/PBR/StockReplacement
  • 'Simple' stock-replacement shader
  • Keywords (grouped by feature-set; only one from each group can be active):
    • Control source of specular value - from DIFF.a, or from MET.a
    • Control source of transparency - from DIFF.a, or from MET.a
• TU/PBR/Metallic
  • Analogue/equivalent to the U5 metallic workflow PBR shader.
• TU/PBR/MaskedRecolor
  • Uses two additional textures to define recoloring setup.
    • The first is the RGB 'section' mask -- main, secondary, detail section specification.
    • The second is the 'base color map' that allows for extracting of the detail data from existing textures by specifying what the 'base' color is for every portion on the diffuse texture.
  • outputColor = (diffuseColor - baseColor) + userColor;
  • Both additional textures are -mandatory- for inclusion/use.
• TU/PBR/ValueRecolor
  • Range/cutoff based recoloring shader.
  • config-specified ranges correspond to the RGB masked portions, so there will be three cutoff ranges specified, one each for 'main', 'second', and 'detail' areas.
  • This will be limited to very basic mask setups, where the base part can contain no more than 3 main colors in any masked area that is to be recolorable.
  • Need to investigate the use of arrays for parameters/uniforms/shader variables. Would like to expand the value-mask function to support an arbitrary list of target values
• TU/PBR/SubSurf
  • Subsurface scattering shader
  • Currently named SSTU/PBR/Solar, will be getting re-named to conform to the TU shader naming scheme.

SSTU shaders being moved back to SSTU

The following shaders will be only distributed with SSTU. Nobody has interest in using them, so they will no longer be distributed with TexturesUnlimited

• SSTU/Masked
• SSTU/PBR/Masked
• SSTU/Solar (legacy solar panel shader)
• SSTU/PBR/Solar shader will stay in TU, but will be renamed to 'TU/Subsurf' or similar.

DONE -- Shader-aware material handling

• Material handling code needs to be aware of specific shaders + functions in order to properly set up the materials.
• Notably, need to maintain a list of shaders with transparency support and any keywords needed to enable transparency support. This is needed in order to properly set up the render-queue for transparent materials (z-buffer / render-order fixes).
• Basic implementation done; need configs setup and shaders actually developed before the feature can be refined.

DONE -- Single texture-switch module for any mesh

• Only a single texture-switch module will be able to interact with any material/mesh. This is because any texture-switch related functions will now create a new material rather than attempting to re-use existing materials.
  • Will re-use the singular material, and assign it to the 'sharedMaterial' slots of any meshes that are adjusted.
• This is the only option to fix 'keyword' and 'value' bleed between texture-sets.
• Unfortunately this means that every value not using defaults needs to be specified in every texture-set.
• Also means that only a single texture-switch module can effect any mesh -- can't have one module switching diffuse textures and a second one switching NRMs -- can only have one.

PresetColor multi-defs

• Preset Color definitions will carry arbitrary values for use by different shaders.
• Will maintain a config defined map of shader names -> color types
  E.G

PRESET_COLOR
{
    name = goldMetallic
    title = Gold Metallic
    //colors specified in <colorType> = <r>,<g>,<b>,<spec/gloss>,<metal>
    legacy = 125, 0, 0, 180, 0
    pbr = 200,0,0,220,255
}

Support optional wholesale shader replacement

• Ability to replace all uses of specific shaders with another specified shader (+ keywords).
• Goal of this is to allow for replacing all uses of 'KSP/Diffuse'/etc with 'TU/PBR/StockReplacement'

Support optional wholesale texture replacement

• Replace specified textures in the GameDatabase with specific replacements.
• Goal of this is to allow for replacing of kerbal suit / skybox / part textures with user-provided replacements.
• Should likely still require config definitions for each replaced texture. Cannot think of any other 'clean' way to handle it. (trying to use folder structure will be a nightmare)

DONE -- Texture Set Parameter Shorthand

• Allow for reading of properties specified through <type> = <name>, <value>
  • Need to support:
    • float -- 'float = _Metal, 255'
    • color-- 'color = _Color, 255,255,255,255'
    • texture -- 'texture = _MainTex, SSTU/Assets/randomTextureName'
    • textureColor -- 'textureColor = _MainTex, 255,255,255,255
    • keyword -- 'keyword = RANDOM_KEYWORD, enable'

Keyword support for shaders.

• Need to be able to both enable and disable keywords.
• ?Need to maintain a config specified list of the default keywords for shaders (for non-texture related functions)
• Ideally the texture-set code would 'know' what keywords corresponded to specific texture slots, and enable/disable those dynamically depending on what textures were in use in the current texture set.
  • E.G. If using a shader with normal map support, and a texture is assigned to the normal map channel, should auto-enable the 'normal map' keyword.
  • Will be a right and proper royal PITA to implement...

TU/StockReplacement

• Enable/disable transparency

'Slotted' texture-switch module support + configs. (possible bonus feature if dev time permits)

• A special texture-switch module that has per-texture-slot controls (diff/spec/nrm/glow), with config options to specify what slots are 'active', as well as the lists of textures for any given slot.
• Ideally this would also need to be able to specify 'groups' of textures -- e.g. for when a normal map has specific corresponding diffuse textures, only allow those diffuse textures to be used.
• So really, this needs to be 'texture sets with multiple options for specific texture slots.
  • The 'texture set' would define the entire selection of textures, including multiple options for specific slots.
  • A module may reference multiple 'texture sets', which would swap the lists of texture options for specific slots.

Please add an optional cfg setting per TEXTURE to enabled real-time light from emissions.

Material.globalIlluminationFlags = MaterialGlobalIlluminationFlags.RealtimeEmissive

Just use REGEX. Problem solved.

Load the search string from the 'mesh = REGEX'. Parse the regex into an object, use it for name comparison search on the transforms in the model

root.getallchildren().where(m=>regex.match(m.name));

Please allow texture layering via cfg. It'd be great if you could also have settings for making the layering dynamic, for example adding a rust layer when a part reaches a certain age and is in atmo or what not.

In Unity, this can be done like so:

    private void AddTextureLayer(Renderer oRenderer)
    {
        Material[] oMaterials = new Material[oRenderer.materials.Length + 1];
        Material oNewMaterial = new Material(Shader.Find("Standard"));

        for (int i = 0; i < oRenderer.materials.Length; i++)
        { oMaterials[i] = oRenderer.materials[i]; }

        oMaterials[oRenderer.materials.Length] = oNewMaterial;
        oRenderer.materials = oMaterials;
    }

It appears that if a part has multiple models defined:
MODEL { model = model1 }
MODEL { model = model2 }

Then the KSPTextureSwitch module ignores the mesh= and excludeMesh= on any but the first model, simply applying the effect to all meshes of the later models.

Debug output from an asset-bundle based model, that should have the 'Airlock' tag on the 'Airlock' transform.

[LOG 17:29:20.893] Transform: GameObject 1(Clone) Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Hab3x Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Cube Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Cube.001 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Cube.002 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Cube.003 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Cube.004 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Cube.005 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: node_collider Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: node_collider2 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Plane Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Plane.001 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Plane.002 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Plane.003 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Plane.004 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Plane.005 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Plane.006 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Plane.007 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Plane.008 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Plane.009 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Plane.010 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Plane.011 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.001 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.002 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.003 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.004 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.005 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.006 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.007 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.008 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.009 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.010 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.011 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.012 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.013 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.014 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.015 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.016 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.017 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.018 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.019 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.020 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.021 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.022 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.023 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Sphere.024 Tag: Untagged Layer: 0
[LOG 17:29:20.894] Transform: Airlock Tag: SmartWater Layer: 21

Anchor it to the FlightIntegrator.ActiveVesselFI.vessel. Update as needed.

Add as a config-file based toggle. Default = enabled.

Should remove the 'blended cubemap' problem

When setting a fairing part to any PBR shader along with properties, the visual is shown to have affected the fairing as well. For example, set the fairing part to metallic mirror and the fairing itself also becomes a mirror; but when changing scenes, the fairing loses its visual change.

From my perspective this can only mean that the code firing when switching between texturesets for KSPTextureSwitch is different from the code that fires during scene load, and the latter is missing something that allows the fairings to be included.

Add a ShaderPropertyOffset and ShaderPropertyScale to allow tiling changes to material textures.

PROPERTY {
name = (texture property name)
offset = 0.0, 0.0
}

PROPERTY {
name = (texture property name)
scale = 1.0, 1.0
}

This would use Material.SetTextureOffset and Material.SetTextureScale.

A practical scenario would be having one textureset that uses a full UVWrap normal map across an entire mesh with another textureset that uses a small tiling pattern for a generic material type.

Whether to use _Metal or _Metallic has been switching back and forth depending on version and which shader you use. Could you please standardize it?

For example, in 1.0.0.5, the stock shader used _Metal, but in 1.0.0.6 it now uses _Metallic again, like it was before.

You may consider refactoring your use of the word Texture for configs. It is being used in place of TextureSet and Material, as well as an actual Texture.

Example where TEXTURE is being used in place of MATERIAL:
KSP_TEXTURE_SET { TEXTURE { ... } }

Example where TEXTURE is being used in place of TEXTURE_SET:
KSP_MODEL_SHADER { TEXTURE { ... } }

• Add checkbox in GUI for symmetry duplication of color settings. Checked by default. Fix symmetry part handling for recolorable GUI in KSPTextureSwitch PartModule.
• Add button 'Cascade' to force current color settings down to all child parts. Also forces all same-name child parts to same pattern setting (if exists).
• Allow vertical and horizontal window resizing to allow more preset colors to show. Save window size to use at next open.

Include a couple free license materials for use with your pbr shaders.

Examples:
https://www.assetstore.unity3d.com/en/#!/content/12949
https://www.assetstore.unity3d.com/en/#!/search/page=1/sortby=popularity/query=category:64

Suggestions:

• Aluminum (diff, norm, met)
• Aluminum Foil (normal)
• Aluminum Scratched (normal)
• Aluminum Dented (normal)
• Aluminum Painted (diff, norm, mask, met)
  • mask should be for paint, which can then have paint color changed via _MaskColor
• Gold
• Steel
• Steel Scratched
• Steel Rusted
• Carbon Fiber
• Kevlar
• Bigelow (Bigelow Aerospace Material)

The recolor gui defaults to changing the first sectionName of the switcher, even if the TextureSet currently selected has recolorable = false.

Suggested behavior:
If all KSPTextureSwitch's on a part are set to a textureset with recolorable = false, then the right-click menu hides the GUI button.

If any section currently is set to a textureset with recolorable = false, then the recolor GUI will not default to that section, but instead the first available section set to a textureset with recolorable = true.

Likely to do with the recent additions/changes regarding render-queue ordering for transparent materials.

(really not sure why it is adjusting a flag mesh that isn't getting adjusted though)

When you have parts in symmetry, it now properly applies the same parameters to each applicable one; but it does not update the visual on the parts that you are not currently touching until after the scene changes.

Due to Mesa providing only OpenGL 3.0 for systems around > 3 years old on Linux, this has resulted in TexturesUnlimited being nonfunctional in this mode and turning all reflective textures black.
This unfortunately may mean systems running OpenGl 3.0 need to revert from the TexturesUnlimited shader to classic Stock shaders to provide functionality.
It's a shame, because the new shader is really nice looking.

EDIT: Issue solved, but changed to a legacy reminder.

Been away for a couple of updates just getting back in and old patches not working and clue ?
`REFLECTION_CONFIG[default]
{
enabled = true
interval = 1
}

@part[*]:HAS[#author[e-dog]]
{
MODULE
{
name = KSPTextureSwitch
sectionName = Appearance
currentTextureSet = AllDefaultMetal

	TEXTURESET
	{
		name = AllDefault
	}
	TEXTURESET
	{
		name = AllDefaultDull
	}
	TEXTURESET
	{
		name = AllDefaultMetal
	}
	TEXTURESET
	{
		name = AllMetal
	}
}

}

KSP_TEXTURE_SET
{
name = AllDefault
title = Default
recolorable = false

TEXTURE
{
	shader = SSTU/PBR/StockMetallicBumped

	excludeMesh = flag
	excludeMesh = FLAG
	excludeMesh = flagTransform

	PROPERTY
	{
		name = _Color
		color = 1.0,1.0,1.0
	}
	PROPERTY
	{
		name = _Metal
		float = 0.0
	}
	PROPERTY
	{
		name = _Smoothness
		float = 1.0
	}
}

}

KSP_TEXTURE_SET
{
name = AllDefaultDull
title = Dull
recolorable = false

TEXTURE
{
	shader = SSTU/PBR/StockMetallicBumped

	excludeMesh = flag
	excludeMesh = FLAG
	excludeMesh = flagTransform

	PROPERTY
	{
		name = _Color
		color = 1.0,1.0,1.0
	}
	PROPERTY
	{
		name = _Metal
		float = 0.0
	}
	PROPERTY
	{
		name = _Smoothness
		float = 0.2
	}
}

}

KSP_TEXTURE_SET
{
name = AllDefaultMetal
title = Default Metal
recolorable = false

TEXTURE
{
	shader = SSTU/PBR/StockMetallicBumped

	excludeMesh = flag
	excludeMesh = FLAG
	excludeMesh = flagTransform

	PROPERTY
	{
		name = _Color
		color = 1.75,1.75,1.75
	}
	PROPERTY
	{
		name = _Metal
		float = 0.75
	}
	PROPERTY
	{
		name = _Smoothness
		float = 1.0
	}
}

}

KSP_TEXTURE_SET
{
name = AllMetal
title = Metal
recolorable = false

TEXTURE
{
	shader = SSTU/PBR/Metallic

	excludeMesh = flag
	excludeMesh = FLAG
	excludeMesh = flagTransform

	PROPERTY
	{
		name = _Color
		color = 1.75,1.75,1.75
	}
	PROPERTY
	{
		name = _Metal
		float = 0.75
	}
	PROPERTY
	{
		name = _Smoothness
		float = 0.75
	}
}

}`
Tells me textures cant be found

Since it seems to be somewhat quick and easy, could you add a couple more keywords to the stock shader?

ALBEDOALPHA_METAL

• denotes that metallicy should be read from alpha channel of albedo

ALBEDOALPHA_SMOOTH

• denotes that smoothness should be read from alpha channel of albedo

*current behavior is ALBEDOALPHA_SMOOTH, but this would allow any combination of inversion, metallicy, and smoothness from the alpha channel

This part will be confusing, so please try to bear with me. In basically everyone's parts whether they be stock or mods, everyone uses various shades of gray as the "metal" color. The attempt here would be specify what the metal color is and the further you get from it, the less smooth or metallic it becomes.

keyword: ALBEDO_METAL
keyword: ALBEDO_SMOOTH
color: _MetallicGlossColor

For the following example, we will assume an _MetallicGlossColor at (127,127,127)
Since we do not want black or white parts to be considered as metal (0,0,0) or (255,255,255); we will set the limits that are 0% to be within 64 RGB; so (63,63,63) and (191,191,191) are 0% in this case.

One minus the RGB difference ratio is what determines the %. In this case, the divisor would be 64+64+64=192. So if the albedo color was 63,127,127 that'd be (1 - (|64 - 127|/192 + |127-127|/192 + |127-127|/192)) = 67%.

Having a variance of 64 seems like a good place to start to me, but may need to be adjusted later depending on what the result would be.

How difficult do you think this would be?

The end result would be that most parts from stock and mods would be set as ALBEDOALPHA_SMOOTH and ALBEDO_METAL with an _MetallicGlossColor set at the shade of gray used for that group of parts.

Might fix problems with linux - openGL compatibility.

Consider the following example:
KSP_MODEL_SHADER {
model = SquadExpansion/MakingHistory/Parts/Engine/Assets/KE-1
model = SquadExpansion/MakingHistory/Parts/SharedAssets/Shroud2x2
model = SquadExpansion/MakingHistory/Parts/SharedAssets/Shroud2x3
//model = SquadExpansion/MakingHistory/Parts/SharedAssets/Shroud2x4
MATERIAL {
shader = SSTU/PBR/Metallic
}
}

If you go in game, the KE-1 and all of its variants will have the shader applied, but none of the shrouds will. Then, uncomment the last shroud, now all of them properly get applied.

I suspect this may be similar to how the fairings work? The shrouds are by default not shown and only become shown after you attach another part at a specific position.

I am thinking that perhaps these models are not found in the direct transform chain and must be found via some other property that simply holds onto a reference and then adds or removes it from the transform chain as needed. (just a suspicion though)

E.g. a GUI that allows selecting from some pre-rendered environment maps:

• kerbin, daylight
• kerbin, night-time
• LKO, light-side
• LKO, dark-side
• Mun orbit
• Mun landed
• others eventually, maybe...

Would also be good if the lights in the VAB/SPH can be adjusted/dimmed to match the env. map.

TODO

• Create Environment maps:
  • kerbin, daylight (full sun)
  • kerbin, night-time (no sun, full galaxy visibility)
  • LKO, light-side (full sun)
  • LKO, dark-side (no sun, full galaxy visibility)
  • Mun orbit (full sun)
  • Mun landed (full sun)
• Create GUI for in-editor use that allows for switching environment maps.
• Figure out how to manipulate the in-editor Lights (probably not hard; grab a reference and manipulate away)
• Create config specifications for the editor lighting for each environment map.
  • VAB and SPH will likely have different configs due to light positions/numbers
  • Might require additional handling for the multiple VAB/SPH levels, as they likely have different Light names/positions/intensities

Please add a title property to TEXTURESET that is used in-game in the GUI switch right-click menu.

This would allow you to have for example Stock_Default, USI_Default, Porkjet_Default, Ven_Default as names with different settings; but visually the player would just see 'Default' as the name of all of them.

It seems that when TU is installed, any parts that make use of the built-in texture replacement from Squad causes a null reference.

Example:
MODEL {
model = model_path
texture = original_tex_name,new_tex_path
}

Something in the back of my head tells me that this has something to do with timing and material replacement.

When neither a mesh nor exclude mesh are set, it will attempt to replace all visible meshrender material shaders with the one specified.

There needs to be a check against transparency though. The materials that were previously using a transparency-enabled shader (such as flag meshes) need to either have their own version of a PBR shader that supports transparency on the diffuse alpha or to just be skipped. I would recommend skipping as there are 3 transparency types and you probably don't want to have deal with all those variations.