Search Issue Tracker
By Design
By Design in 2023.2.X
Votes
3
Found in
2023.1.0a1
2023.2.0a1
Issue ID
UUM-3277
Regression
No
The Material's shader is not fully set when switching the shader in Player
How to reproduce:
1. Open the attached project "ShaderSystemIssue.zip"
2. Open the "SampleScene" Scene
3. Build And Run (File > Build And Run)
4. When the Player loads press the Button labeled "Button" two times
Expected result: The Material of the "Cube" GameObject switches to "Lit"
Actual result: The Material of the "Cube" GameObject becomes transparent
Reproducible with: 2019.4.38f1, 2020.3.34f1, 2021.3.2f1, 2022.1.0f1, 2022.2.0a12
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Texture2D hash changes inside of an AssetBundle when rebuilding a SpriteAtlas bundle with an empty AssetPostprocessor Script enabled
- Aniso Level still applies when Generate MipMap is disabled in Texture Import Settings
- Mipmap Limit Groups long names are not truncated when creating a new Mipmap Limit Group with a long name
- “ArgumentException: Invalid double parameter.” error is thrown when Infinity is typed into the Fixed Timestep field
- GameObject becomes gray when using HDRP and STP together on macOS
Resolution Note:
When setting the shader, the customRenderQueue is resetted in the material. So when the user set it back to the previous shader, the visual is different because the customRenderQueue is resetted to use the default one.
What is happening here is the intended behavior according to the [documentation |http://example.com]:
"Note that if a shader on the material is changed, the render queue resets to that of the shader itself."
The recommendation here would be to let the user know that he should also set the customRenderPass when setting the shader if he doesn't want to use the default shader one.
Resolution Note (2023.2.X):
When setting the shader, the customRenderQueue is resetted in the material. So when the user set it back to the previous shader, the visual is different because the customRenderQueue is resetted to use the default one.
What is happening here is the intended behavior according to the [documentation |http://example.com]:
"Note that if a shader on the material is changed, the render queue resets to that of the shader itself."
The recommendation here would be to let the user know that he should also set the customRenderPass when setting the shader if he doesn't want to use the default shader one.