Jump to content

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


Shadowmage

Recommended Posts

It does use PartVariants and is working fine in the recolour project but I switched from "black listing" to "white listing" meshes a while back due to chasing tales of other mods that "replace" stock parts.

  Reveal hidden contents

 

Link to comment
Share on other sites

  On 10/18/2019 at 7:39 PM, Shadowmage said:

Have a config that you wouldn't mind sharing?

Expand  

Sure, here's the relevant section of the config. I left out the definition for Roverbody_VSR as it doesn't seem to matter here.

KSP_TEXTURE_SET
{
	name = Roverbody_White
	MATERIAL        
	{
		shader = TU/Metallic
		PROPERTY
		{
			name = _Metal
			float = 0.7
		}
		PROPERTY
		{
			name = _Smoothness
			float = 0.97
		}
		excludeMesh = Flag
		keyword = TU_STOCK_SPEC
		texture = _MainTex, Squad/Parts/Command/probeCoreCube/QBE_New_diffuse
		texture = _BumpMap, Squad/Parts/Command/probeCoreCube/QBE_New_NRM
	}
}

@PART[roverBody]:FOR[TU_VSR]:NEEDS[VenStockRevamp]
{
	MODULE
	{
		name = KSPTextureSwitch
		textureSet = Roverbody_VSR
	}
}

@PART[roverBody_v2|ChopShop_RoverXL]:FOR[TU_VSR]:NEEDS[VenStockRevamp]
{
	@MODULE[ModulePartVariants]
	{
		@VARIANT[VSRGrayAndBlack]
		{
			EXTRA_INFO
			{
				textureSet = Roverbody_VSR
			}
		}
		@VARIANT[White]
		{
			EXTRA_INFO
			{
				textureSet = Roverbody_White
			}
		}
	}
	MODULE
	{
		name = TUPartVariant
	}
}

I figured I wouldn't have to patch Gold and Silver because they already are reflective. White is patched because it's the only stock variant with normal shaders applied.

Edited by Delay
Link to comment
Share on other sites

  On 10/18/2019 at 9:52 PM, Manwith Noname said:

you'll want to setup each variant to use Texture Sets.

Expand  

I don't want to modify any of those variants. I'm happy with them the way they are. Heck, I'm only modifying the stock (even though with Ven's installed there's no need to) merely to keep things consistent*.

*Well, @Shadowmage and I know of one Ven's part that can't be patched. Rest assured, though: As far as I can tell the Skipper is the only part that behaves strangely.

Link to comment
Share on other sites

@Delay

No need to guess anything for those rover body probe cores, it's all there in the part config, the shader, the mesh names, values for shader input...

  Reveal hidden contents

At most, for other parts you might have to guess at the shader in use but you can very much make an informed choice as there aren't that many part shaders used by Stock parts, though this might change somewhat with new releases perhaps but they'll probably end up just using two or three. Most new parts use a form of bumped spec, for example. Even then, I suspect you could probably import the models to blender or part tools and extract the information more accurately but I've never felt the need to go that far. Some shaders you might find useful...

  Reveal hidden contents

Utility mods like DebugStuff and Object Inspector are at your disposal too for unearthing hidden secrets.

Edited by Manwith Noname
Link to comment
Share on other sites

  On 9/9/2019 at 10:11 PM, Shadowmage said:

Shouldn't be any breakage on the config end of things either -- as far as I know at this time, nothing should really be broken by the update.

Expand  

Well I hate to be the bearer of bad news and it is most certainly not your fault. Might not even be fixable on your end? But it looks like TU is totally screwed up under GLCore for Linux users. Shaders   work fine under Windows Dx11 as do all my old configs. But installing just TU under GLCore without even config files kills all the native shaders. And config files oversaturate everything they touch. Not asking for anything just a heads up and wondering if anyone else on Linux GLCore is reporting problems?

Edited by Delbrutis
Link to comment
Share on other sites

  On 10/20/2019 at 6:31 PM, Manwith Noname said:

No need to guess anything for those rover body probe cores, it's all there in the part config, the shader, the mesh names, values for shader input...

Expand  

So... I just tried this and now I can't get color to any of the maps. They're just white.
What's confusing me most is what name I should give to each map - the TU names (_MainTex, _MetallicGlossMap, etc)? Or the KSP names?
The gold diffuse actually has the color in it, so my conclusion is it doesn't load the map. But it loads the specular just fine, same with the bump map?

Link to comment
Share on other sites

@Delay

Texture assignment follows the same conventions but for this particular shader you want to point with _SpecMap rather than _MetallicGlossMap.

I did take a look and compare my sets with the default stock look in 1.8 and it's not exactly spot on with the same shader values applied. It's noticeably less shiny but then I remembered a previous conversation on this when the shader was first introduced. I'll dig back through the thread and link it in a bit.

 

Edit: Essentially, start here. Though, that test I think was applying TU metal shaders with stock files as opposed to applying the stock shader through TU texture sets.

Edited by Manwith Noname
Link to comment
Share on other sites

  On 10/21/2019 at 9:53 PM, Manwith Noname said:

_SpecMap

Expand  

I tried using _SpecMap, the result was having no specular map...

As I've said, using TU names everything sans main texture (and with that the model's color) appears to work just fine. I have nice lines of different shades and different specularities, but a perfectly white part when it should be gold.

Link to comment
Share on other sites

@Delay

Here's my texture sets...

  Reveal hidden contents

Yes, those texture sets might look odd and different but the end result is the same, I was just testing what works and if results change. I've been meaning to do more testing to make sure the fields are actually being applied but given the end result is pretty close to Stock and without any of them, the result was way off, I kinda moved on with the intention to go back once I had other things I wanted to address sorted.

 

You could of course build your pack to utilise the standardised switching and follow the concept of adding extra sets with all the heavy lifting already in place. That was mainly the point of the permissive license and structure taken within TURD. The Standardised Switching and placeholder textures was to enable everyone making packs to play in the same sandpit and not waste others time and hard work. I've also toyed with the idea of bundling fixed version of the problematic emissive textures in here. I just never got round to uploading it as a separate download outside of the recolour pack because Squad keep changing everything (which they've done again with all the nose cones) and it was one less download to keep updating. This is also why the "Extras" pack, which contained a generic "make things shiny" set has been bundled back in the main recolour download. The real idea behind that metallic file was a "stop gap" and to give a template that anyone making metallicglossmaps could simply change the texture set names, change the [FOR] number for ordering and point to their textures without needing to write the entire config from scratch.

Link to comment
Share on other sites

@Delay

Given what you've just done, first thing that springs to mind, make sure it's "mesh" and not "Mesh", case is important. Though, this is kinda back to square one anyway so it's probably not that. Are you using the latest release of Textures Unlimited? I'm off out but it might be an idea to open up the module manager cache file and look at how the patch ends up. Search for roverBody_v2, check out the entire part and that it looks like you intend. Maybe copy that here along with how the texture sets appear. You'll have something like this...

  Reveal hidden contents

I didn't put all my texture sets in because I'm pushed for time but you get the idea. As previously, this is working for me in 1.7.3 with TU 1.5.8.23. In fact, it also works in 1.8 surprisingly though there are some things not quite right underneath. Mainly icon and GUI related but I didn't expect it to wok at all.

Link to comment
Share on other sites

Oh... This is what the section looks like for me.

VARIANT
{
	name = Silver
	displayName = Silver
	themeName = Silver
	primaryColor = #cecece
	TEXTURE
	{
		shader = KSP/Bumped Specular (Mapped)
		mainTextureURL = Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2_silver_diffuse
		color = #ffffff
		_BumpMap = Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2_silver_NRM
		_SpecMap = Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2_silver_specular
		_Shininess = 0.82
		_Opacity = 1.0
		_RimFalloff = 2.0
		_AmbientMultiplier = 0.3
	}
	GAMEOBJECTS
	{
		bodyWhite = false
		bodyFoil = true
		Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2(Clone) = true
		VenStockRevamp/Squad/Parts/Command/ProbeCores/RoverProbe(Clone) = false
	}
	EXTRA_INFO
	{
		textureSet = Roverbody_Silver
	}
}

Not sure that's right...

Link to comment
Share on other sites

Ok. Something I noticed earlier when you posted your patch config and checked on my end, so you can do this or not as it didn't cause me issues but might be worth doing just for the sake of it, the default TEXTURE section can be deleted when TU is handling everything. I suspect it either gets ignored or overridden when "TUPartVariant" is present. Essentially I commented that part out of my patches to check at the time and I didn't get any issues with the flag mesh. It's just a small line in the setup though, example patch...

  Reveal hidden contents

What does look like it could cause issues but might not and could be worth checking is the extra line in "GAMEOBJECTS". I get you have that because you are adding Ven's probe core in here but without seeing the rest of the part setup or looking in to adding other models to a single item and selecting them through variants, I would test commenting out those lines so for stock probe core variants, just use standard meshes as found in the config. So it would end up something like this...

  Reveal hidden contents

...or even without the Ven's pointer too. Then, in your Ven's sets, set it up so you do disable everything Stock (this might need the stock path with false) but have Ven's model path as true. I can kinda test this idea without installing Ven's so I'll do that in a minute. I'm not sure if enabled objects in other variants stay on or disabled when switching variant.

 

Edit:

 

Hmm, well, I was able to add that line without any ill effects. I kinda expected it might cause duplicate model loading and show signs of z fighting.

 

Another Edit: Oh, I just had another thought. Do you have any TU config files you've downloaded installed? Like perhaps the one that appeared on SpaceDock that blanket applies TU shaders via MODEL_SHADER? I'm smelling a conflict of some sort. Probably best to remove any configs other than what you are creating. You really want a clean install with only the specific things you are working on installed, then you'll know if you've messed up, or someone else. Perhaps, remove only your configs and see if the part behaves the same with everything else still installed.

Edited by Manwith Noname
Link to comment
Share on other sites

  On 10/25/2019 at 1:07 AM, Manwith Noname said:

Do you have any TU config files you've downloaded installed? Like perhaps the one that appeared on SpaceDock that blanket applies TU shaders via MODEL_SHADER? I'm smelling a conflict of some sort.

Expand  

The only configs that mention TU in my install are mine and the sample Shadowmage gave me as a start. I don't have any other TU configs installed.

 

While we're discussing this problem, I should also mention that I've run into similar issues with probe cores. Kerbas left the Squad revamps available as a part variant, and switching the variant to Squad's directly on the mesh retains the Ven's textures, which looks.... interesting. Different UVs and all.

Switching the variant in the part selection however and then adding the Squad part into the scene causes absolutely no problems, everything behaves fine. Switch to Ven's and back and things look odd again.

Edited by Delay
Link to comment
Share on other sites

@Delay

Right, fun for today. I installed VSR and without doing anything other than that...

  Reveal hidden contents

So, I setup VSR parts to use TU...

  Reveal hidden contents

...and I scratch my head for a bit because it works. Then, on a hunch, I remove the whitelisting in the VSR texturesets, the one thing I haven't seen relevant to this discussion...

  Reveal hidden contents

Strangely, I get the stock normal map overlaid rather than a gold foil texture.

TL:DR, whitelist your texture sets correctly.

Link to comment
Share on other sites

There's certainly a case to be made that something isn't behaving right in TUPartVariants mind you. It's weird that not defining the mesh in the VSR core set, breaks the definitions within other sets which are technically set up right. This is however perhaps "not intended usage" of both Stock variants and TU in my mind, even if it can be made to work.

Link to comment
Share on other sites

  On 10/25/2019 at 5:22 PM, Manwith Noname said:

It's weird that not defining the mesh in the VSR core set, breaks the definitions within other sets which are technically set up right.

Expand  

What puzzles me is that at the very beginning I wasn't even applying a patch to the Silver and Gold variants. After that I did have the material definition and now after whitelisting VSR the part works just fine without one!

Link to comment
Share on other sites

Is it possible to reuse parts of a textureSet for different variants?
Right now I'm redefining the same things over and over again because one thing is different for each variant. That's not only annoying because if I change one thing I have to change it everywhere, it also blows up file length and makes things less readable.

Ven's uses part variants to make different attachment sizes possible. The Ant (what I'm patching right now) can fit onto size 0 and size 1 this way, and it would be nice if I could use the same code for the nozzle without having to rewrite it.

 

Edit: Okay, in this case I can handle everything through just one material. The adapter is only enabled in on of them anyways.
Edit2: No I cannot. The textures for the  adapter don't show up, instead the engine texture does. Applying separate materials to the variants solves that.

Edited by Delay
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...