Bug Material too dark

I'm currently facing a weird bug I've never seen before and I hope that someone can help me out!

I have an addressable scene with a mesh that has an addressable material assigned to it. The problem there is that it looks way too dark



When getting closer I can see the texture so the material is applied but the shader seems to be the problem. As seen on the left there is this WorldSpaceUV-app shader applied.
Now comes the weird thing: If I reassign this exactly same shader again by just clicking on the blue highlighted dropdown menu entry the wall fixes itself and looks like this



As said I did nothing but clicking on the exact same shader again and reapplying it. As the green tick indicates it is really the exact same shader. None of the values changes at all. Whats going on there?

I wrote a script that immitates this behavious by reassigning the shader automatically. It works fine in the editor but when building it's not working anymore. Seems all weird to me as I'm no expect with shaders.

Has anyone got an idea what's wrong there and how I could fix this?

 

I wonder if this is a shader bug?

 

Yes could be. We did some intensive research on this problem and have some more details:

We serialized the material before and after reassigning and compared both results. We found a difference in the materials' shader passes: Before reassigning when the material is dark there are only three different shader passes, namely FORWARD, FORWARD and DEFERRED. After reassigning there is one more render pass called 'Meta' which seems to be crucial for lightmaps.

But the addressables were build from the exact same project with the exact same shader. So it looks like the meta pass is lost when build or loading the addressable.

 

Could be missing shader variants.

Unity strips all shader features (#pragma shader_feature) that it doesn't find in materials when you make a standalone build. That's a problem, because not all keywords are set in materials.

You can fix this by recording a shader variant collection and putting the shader variant file into the same bundle as the shaders (I assume, it's the same for addressables).

https://support.unity.com/hc/en-us/...ow-to-use-Shader-Features-with-Asset-Bundles-

 

Thanks a lot for your answer!

Your hint explains our problem perfectly: The addressable shader is stripped that's why it's not displayed correctly. As soon as we try to reassign the shader (in the editor) it works because this time the project's unstripped shader is used and we have a correct lightning again. But once we try to apply this fix to the build it's again not working because the project's shader got stripped when building the app. So everything seems to fit your hint!

There is just one problem left: we can't fix it?! What we tried:

• Use "Keep All" in Graphics -> Shader Stripping
• Add shader to "Always included shaders"
• Add shaderVariantCollection to preloaded shaders
• Add shaderVariantCollection to addressables

That's what our settings currently look like:





All steps together don't fix the problem! So it seems like the shader is still stripped. What are we missing to avoid the stripping?

We tried another thing: We added two cubes to our start scene from where addressables are loaded. Both cubes have our shaders applied. When starting the app the look exactly as they should. But once we load the addressables including the stripped shader the cubes turn black. So it looks like the addressable shader overwrites it's local version (that's why we tried to copy the shader ("WorldSpaceUV-app-runtime")).

So it looks like we've found the problem with your hint. But what is still wrong?

 

Sorry to hear that it still doesn't work. As far as I can see, you are doing it correctly.

A few more things you could try:
- Replace #pragma shader_feature with #pragma multi_compile in the shader. That could cause long compile times because it generates all combinations of variants but should be a way to confirm or dismiss the theory
- Add #pragma enable_d3d11_debug_symbols to the shader and take a RenderDoc capture. If it uses a wrong variant, you know that the theory is correct. If it's something else, you should also see what's going on.
- Select the shadervariants file to check if all variants of your shader are included. You first have to play the game before you save the shadervariants file.

It could be something entirely different. It's just a guess. I'm just mentioning it because I've had a very similar problem and this was the cause. It could be as simple as an unset shader parameter.

 

Hmm thanks again for your help but we couldn't fix this yet.

We know about this problem and checked it but the shader variant file seems to be correctly.

Haven't tried this one yet, might do this tomorrow

Tried it but didn't fix the issue

I also thought this problem could be caused by some bugs in the Unity Editor so I tried different version namely 2020.3.16f1, 2022.0.0b5 and 2022.0.8f1 but this problem wasn't fixed either.