[1.9.x] Textures Unlimited - PBR-Shader, Texture Set, and Model Loading API

[Shadowmage]

1 minute ago, Electrocutor said:

While I am digging through the stock textures, one thing has become obvious: Squad did not make nor save the normal maps correctly. Even just opening them and re-saving them properly makes the parts look twice as good.

I was wondering how long it would take someone to try and pick up a stock-texture-conversion   I'm very interested to see how it all goes, and please let me know if you run into any other technical issues or have general questions.  The stock-conversion shader was a bit of a last-minute addition, so it may well need some changes in order to serve its purpose better.

Hopefully I'll have the full documentation done over the next few days; still a bit busy converting SSTU over to use the new shaders and plugin...so many configs and models to adjust.

[Foozle]

16 minutes ago, Electrocutor said:

While I am digging through the stock textures, one thing has become obvious: Squad did not make nor save the normal maps correctly. Even just opening them and re-saving them properly makes the parts look twice as good.

Alas, I think licensing issues prevent distributing improved Squad normal maps.

A batch process for doing that using open source tools, however...  Hmm.

And it would work for mods, as well.

Edited November 12, 2017 by Foozle
D'oh!

[Electrocutor]

4 minutes ago, Shadowmage said:

I was wondering how long it would take someone to try and pick up a stock-texture-conversion   I'm very interested to see how it all goes, and please let me know if you run into any other technical issues or have general questions.  The stock-conversion shader was a bit of a last-minute addition, so it may well need some changes in order to serve its purpose better.

Hopefully I'll have the full documentation done over the next few days; still a bit busy converting SSTU over to use the new shaders and plugin...so many configs and models to adjust.

The biggest problem here is that I'm not an artist by any means; all I can do is take other people's work and try to put the right shaders and parameters on them. The ideal would be for Squad to go back to their source files and re-export textures properly and at a higher resolution where available.

I'll do what I can with stock stuff without having new textures, then see from there. Honestly, there isn't a single part mod that shouldn't make use of this.

[Foozle]

1 hour ago, Shadowmage said:

I don't think there is anything in the plugin that would prevent it from working on KSP 1.3.  You can always give it a try    (AVC might complain, but it should still load and function)

(i.e. it shouldn't even need a recompile, but I haven't tested it)

Here we go...

KSP loaded successfully, no crash...                             check.

VAB category present...                                                    check.

Parts are accessible   *OOOH, SHINY! *                        ahem, check.

This thing is gorgeous.

And it works in 1.3, just as you said it would.

 

Kottabos, where art thou?  You ain't gonna wanna miss this...

[vossiewulf]

1 hour ago, Electrocutor said:

While I am digging through the stock textures, one thing has become obvious: Squad did not make nor save the normal maps correctly. Even just opening them and re-saving them properly makes the parts look twice as good.

That sounds like it's worth a mini-mod, especially for anyone who wants to run stock- it's a mod that would just be making Squad content look like it was intended to and shouldn't break stock status.

Everyone else should be running Venn's

 

[Foozle]

11 minutes ago, vossiewulf said:

That sounds like it's worth a mini-mod, especially for anyone who wants to run stock- it's a mod that would just be making Squad content look like it was intended to and shouldn't break stock status.

Everyone else should be running Venn's

 

Everyone who can afford that much memory, anyway 

I would love to run full Ven's but had to trim it down to just the new parts.

Too many mods, too many mods...

[Electrocutor]

1 minute ago, Foozle said:

Everyone who can afford that much memory, anyway 

I would love to run full Ven's but had to trim it down to just the new parts.

Too many mods, too many mods...

You must not be running KSP_x64?

[Foozle]

Just now, Electrocutor said:

You must not be running KSP_x64?

I'm on OSX, actually.  But I use a lot of mods and performance gets very laggy above 9GB.

[Electrocutor]

Just a quick example. This is stock except I replaced the shader and picked a different normal map...

Bob: "I found it like this when I came in this morning..."
Bill: "Seriously? As if I don't already have enough work to do!"
Jeb: "Err... They promised that the roller derby was harmless. By the fourth lap, though, I suspected something was up."
Val: "*snicker*"

Spoiler

@REFLECTION_CONFIG[default]
{
	%enabled = true
}

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

	TEXTURE
	{
		shader = SSTU/PBR/StockMetallicBumped
		mesh = SideWindow
		mesh = FrontWindow

		texture = _MainTex,TexturesUnlimited_Stock/Textures/white
		texture = _BumpMap,TexturesUnlimited_Stock/Textures/bump

		PROPERTY
		{
			name = _Color
			color = 0.5,0.5,0.5,0.8
		}
	}
}

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

	TEXTURE
	{
		shader = SSTU/PBR/Metallic
		mesh = OuterShell

		texture = _BumpMap,TexturesUnlimited_Stock/Textures/metal_n
		texture = _MetallicGlossMap,TexturesUnlimited_Stock/Textures/bump
		texture = _AOMap,Squad/Parts/Command/Mk1-2Pod/mk 1-2 external shell Variant-Hatch
	}
}

// white is a single pixel dds (1,1,1,1)
// bump is a single pixel dds (0.5,0.5,1,0.5)

 

 

[Temeter]

That's horrifying.

 

And I love it!

[vossiewulf]

On 11/11/2017 at 12:18 PM, Shadowmage said:

Momentary brightening of reflections when vessels are decoupled/undocked

That's... odd  I'm not sure I want to know what quirk of the underlying framework is causing that. Do I want to know?

 

[Shadowmage]

1 minute ago, vossiewulf said:

That's... odd  I'm not sure I want to know what quirk of the underlying framework is causing that. Do I want to know?

 

I'm not even sure if it is still present, haven't tested it/seen it in awhile.  I believe the cause is/was that I add one reflection probe per-vessel, and their boundaries/influence would momentarily overlap when the new vessel was created.  It could also have been related to the fact that I would parent the probe to the vessel object, so it might have been getting duplicated by KSP code when the vessels decoupled;  I now leave the probes as parent-less and manually update their position, so that should no longer be a potential cause.

[Electrocutor]

So... this is the stock 2-1 Command Pod after editing the stock Normal to flatten the alpha channel into Red-127, shift the green channel so it's neutrally at Green-127 (instead of 63), shifting the blue channel so it's neutrally at 255 (instead of 63), and saving as DXT5nm; then setting it to metallic. Compared to just using some of the good model and texture replacement mods, I'm not sure it's worth messing with the old stock textures?

[Electrocutor]

Okay... I'm convinced. Most of the default textures seem to be setup pretty well to run with a metallic shader. I'm going to break it down into sections though. Here is the Mk1 cfg with no changes except to set them to the new shader.

[Electrocutor]

Just rolling around and watching how things look: I think you have a problem with the reflectionprobe or lightprobe placement; it seems to be very jittery instead of being set relative to the vessel, and appears to randomly become occluded from light sources sometimes.

Edited November 13, 2017 by Electrocutor

[Shadowmage]

3 minutes ago, Electrocutor said:

Just rolling around and watching how things look: I think you have a problem with the reflectionprobe placement; it seems to be very jittery instead of being set relative to the vessel, and appears to randomly become occluded from light sources sometimes.

The probes are only updated once per second (at most; depending on frame-rate; could be as seldom as once every 3-4 seconds).  It is set to auto-follow the vessel.transform.position on every frame, so that cannot be a cause.

Would you mind uploading an otherwise stock craft file that exhibits these problems so that I might do some debugging (and/or whatever other files are needed)?  (cannot fix that which I cannot see or reproduce; and I've never seen the problems you are describing)

[Electrocutor]

2 minutes ago, Shadowmage said:

The probes are only updated once per second (at most; depending on frame-rate; could be as seldom as once every 3-4 seconds).  It is set to auto-follow the vessel.transform.position on every frame, so that cannot be a cause.

Would you mind uploading an otherwise stock craft file that exhibits these problems so that I might do some debugging (and/or whatever other files are needed)?  (cannot fix that which I cannot see or reproduce; and I've never seen the problems you are describing)

Spoiler

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.

[Shadowmage]

12 minutes ago, Electrocutor said:

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.

If you run into any other information regarding that problem, please add it to the issue ticket below:

https://github.com/shadowmage45/TexturesUnlimited/issues/8

Would you mind including a KSP.log file on there as well, in case there are some platform/environment issues involved?

(and I have to make sure.... you are using OpenGL or DX11, correct?  There are some very notable problems under DX9 that exist in Unity that I cannot solve)

[Electrocutor]

DX11; I can try OpenGL and DX12 later to see if it makes a difference, but from what I am seeing, it is acting like what I've seen myself when a ReflectionProbe is not set to transform relative to a moving object and is sometimes having its light sources occluded by the very object that it is supposed to be projecting onto.

[Shadowmage]

54 minutes ago, Electrocutor said:

DX11; I can try OpenGL and DX12 later to see if it makes a difference, but from what I am seeing, it is acting like what I've seen myself when a ReflectionProbe is not set to transform relative to a moving object and is sometimes having its light sources occluded by the very object that it is supposed to be projecting onto.

Yeah, is a bit puzzling as the probes are certainly moved along with the vehicle.  The rendering mask also excludes the rendering of vehicles/parts/etc, so there should not be any self-occlusion problems.

Even more puzzling is that I have not seen anything similar with the SSTU parts and launching rockets; no flicker on the pad, nor during ascent, nor in orbit.  The only anomalies that I've encountered have been related to KSPs view-direction-dependent skybox darkening/lightening (depending on camera orientation compared to the sun, the skybox is dynamically adjusted to simulate HDR; nothing I can do about it), and scatterers' ocean-renderers not updating properly (long-standing scatterer problem; need to open up the debug menu and rebuild ocean renderers).

[Electrocutor]

In my own testing, I just did this so I never have to think about updating the probe location since it's location is the same object as the vessel's location.

oProbe.center = oVessel.CurrentCoM;

I also set the size to be 1 greater than the furthest x,y,z colliders on the vessel.

[Shadowmage]

6 minutes ago, Electrocutor said:

In my own testing, I just did this so I never have to think about updating the probe location since it's location is the same object as the vessel's location.

oProbe.center = oVessel.CurrentCoM;

I also set the size to be 1 greater than the furthest x,y,z colliders on the vessel.

Due to how I had to set up the probes, I cannot parent them directly to the vessel, so simply setting the probes center won't fix the problem (the probes location also needs to be updated).  Though I don't think that offsetting it by the COM would fix the problem anyway -- the bounds are already setup to something silly like 2000m; it should encompass anything within physics range of the currently active vessel. 

So I doubt the problem is related to either the probes position or its bounds.

 

[Electrocutor]

I took a quick peak at your reflection code; you might try this:

        public void vesselCreated(Vessel vessel)
        {
            ReflectionProbeData data = createProbe();
            //data.reflectionSphere.transform.position = vessel.transform.position;
            data.center = vessel.CurrentCoM;
            VesselReflectionData d = new VesselReflectionData(vessel, data);
            vesselReflectionProbeDict.Add(vessel, d);
            MonoBehaviour.print("SSTUReflectionManager vesselCreated() : " + vessel+" :: "+d);
        }

This will make it so the probe's Vector3 object is the same object as the vessel's Vector3 object; meaning anytime the game moves the vessel, the probe is auto-moved along with it.

 

In my own test, I also created the probe within the vessel, so if the game destroys the vessel, it will also destroy the probe.

ReflectionProbe oProbe = oVessel.gameObject.AddComponent<ReflectionProbe>();

 

Edited November 13, 2017 by Electrocutor

[Shadowmage]

@Electrocutor

I noticed an error in the packaging for the mod that was causing two .dll's to be included; both of them would be trying to run, likely only one of them with any success.  Could you check the 000_TexturesUnlimited/Plugins folder to see if there are one, or two .dll's present?  If there are two of them, you can delete the "0_TexturesUnlimited.dll" copy.

This might be the cause of some of the oddies that you were seeing (I haven't been able to replicate them so far).

[Electrocutor]

1 hour ago, Shadowmage said:

@Electrocutor

I noticed an error in the packaging for the mod that was causing two .dll's to be included; both of them would be trying to run, likely only one of them with any success.  Could you check the 000_TexturesUnlimited/Plugins folder to see if there are one, or two .dll's present?  If there are two of them, you can delete the "0_TexturesUnlimited.dll" copy.

This might be the cause of some of the oddies that you were seeing (I haven't been able to replicate them so far).

I had noticed the second copy during install and have only ever had the one. Are you unable to reproduce the issue? I have a 100% fresh copy of KSP with only MM and this right now.

 

[Edit] Just tried with both dx12 and OpenGL; no difference.

These screens were taken about 10 meters from each other at almost the same time, but one looks like it should be in broad daylight while the other after sunset when everything turns dark.

Spoiler

Edited November 14, 2017 by Electrocutor