Wat? No highlights from my lights?

punchface

I'm hoping this is a really easy question. I have my model. I have a back backdrop. I have a couple of point lights and my direct light which is supposed to be the sun. My model's material was made in Shaderforge and is using the "PBL" with forward rendering. Color, roughness, metallic, normal, AO, and Emissive are all texture maps.

I have no Specular highlights. I have reflection from my probes and that seems to be working correctly and I can clearly see where my lights are making stuff brighter and illuminating them. But no highlights. WTH?

Here's my model in Painter where the highlights are clearly showing (I've outlined 'em in red) which are totally absent in Unity:

Eric Chadwick

Unity default PBR shader uses a particular layout for glossiness. It has to be stored in a specific color channel. It could be your Shader Forge shader expects the same?

punchface

Why thank you, Chadwick. I'll try that. It never occurred to me that a game engine could have OCD.

punchface

Bahh...it didn't help. Further, my log is full of errors and warnings:

Eric Chadwick

Google the error message? 

punchface

That first one about Type A:VTv1 Type B: VTv3 didn't turn up much but the longer NullReferenceException thing got more hits. I've given up on the gun for Unity and just put it in Toolbag and did my  renders and moved on with my work...But I'll try Unity again as a rendering environment for my next project so it'll still do me good to understand at least a little bit of what has happened here. I'll do more poking around and trying to figure out what those error messages mean. Without the pressure (self-created, obviously) of being really close to being done with something and WANTING to be done, things should sort themselves out. Also, I'll go slower next time around and be more mindful of what I'm doing so the moment something weird happens, I'll have a really good idea of what I did specifically to make a change that caused the hiccup.

For what it's worth, Chadwick, a guy in a Unity group geographically close to me sent me a url to a download of a bunch of RGB color and brightness calibration stuff for various basic surfaces (wood, concrete, various kinds of metals, etc.)  so that I could try adjusting my texture maps for effect. It didn't help either although the charts were pretty cool and I'm keeping 'em.

Thanks for your time, sir.

cptSwing

It seems like you are connecting nodes that aren't meant to be connected.. ie a color node into a node expecting a greyscale input or something to that effect.

punchface

That would definitely be something to look at in the future. The thing that I noticed about Shader Forge so far is that if you try and put an RGB link into a node that wants a single grey channel input is that it won't take it which would suggest to me that this isn't the problem HOWEVER, Chadwick's initial sorta/kinda voodoo suggestion that maybe the issue was simply that what Unity wanted was a metallic map with roughnesss/smoothness is the alpha or it wouldn't work right comes to my mind.

Before Chadwick said that, I already had my roughness data in R, G, and B of a texture with Metallic as an alpha. R was going into roughness while A was going into metallic. In theory, there was no reason why that shouldn't have worked because both inputs were getting the kind of data that they wanted.

After Chadwick's first feedback, I called this possible behavior on the part of Unity "OCD" like Unity was neurotic or finnicky because the idea would be that it's not enough to feed the right kinda data into the correct inputs, it had to be served up on the platter in just such a way or Unity would just say "no". This to me is totally friggin' silly and irrational but it wouldn't have been the first time that I ran into a computer program problem that was just like that.

So anyway, I guess what I"m saying is that just because I can say "nah, man Shader Forge won't let me put a color linkage a node that wants grey and so it can't be that." doesn't mean you're not right.

punchface

Because communicating gratitude is good, I just want to say it again: Thanks you both for your time. Time is the one thing in life that we can't really get back so thank you, really.

cptSwing

Hah, no worries. Sometimes when switching shader variants in SF, ie Gloss/Spec to Metal/Rough, it will leave old node connections even if they're not viable. Of course, it could be lots of other things in your shader, depending on complexity. A node expecting a Vector3 value instead of a Vector1 or something. Though yes, usually there should be failsafes to stop you from doing it.

As for your channel packing, personally I wouldn't pack my metalness map into an alpha channel if indeed I'd need an alpha. DXT5 alpha channels are barely compressed, so you should use it for a map that needs more fidelity, a metalness usually being little more than binary black/white. Since the alpha is so conservatively compressed, one DXT5 with 4 channels is approximately the same size as two DXT1 textures with 6 channels altogether - switching to two mixmaps might make more sense. The wiki has more on this, if you're interested. Generelly, I store the more detailed maps (like roughness) in the green channel since it's compression uses higher bit depth in DXT. Obv. all of this is valid for pc, firstly. And if using Unity just for showcasing an asset, I wouldn't bother with channel packing and compression and any of that anyway, because.. why?

punchface

The wiki has more on this? Hahah...I wish you could see the stupid face I'm making right now. I'm like a little boy in a candy shop! You mean the polycount wiki or some Unity-centric wiki on the Unity website?

Eric Chadwick

your search foo is weak

punchface

Sorry to disappoint you, Chadwick.

Eric Chadwick

Can you find it?

Also, your signature link is borken.

punchface

Yup. I found it.  I found stuff about DXT compression here and also on wikipedia.