Search Issue Tracker
Fixed in 2022.1.X
Fixed in 2020.3.X
Votes
0
Found in
2020.2.4f1
2020.3.12f1
2021.1
2021.2
2022.1
Issue ID
1346626
Regression
Yes
Material appearance changes when Shader is using #pragma multi_compile_particles
Reproduction steps:
1. Extract and open the attached project (MCPIssue)
2. Open scene Scenes/SampleScene
3. Observe the two spheres in the Scene view
Expected result: Both spheres look the same
Actual result: The spheres look different
Reproducible with: 2020.2.4f1, 2020.3.13f1, 2021.1.15f1, 2021.2.0b3, 2022.1.0a2
Not reproducible with: 2018.4.33f1, 2019.4.28f1, 2020.2.3f1
Note:
- The only difference between the shaders is that one uses '#pragma multi_compile _ SOFTPARTICLES_ON' whereas the other one uses '#pragma multi_compile_particles'
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 (fix version 2022.1):
Fixed in 2022.1.0a14
multi_compile_particles was mutually exclusive with other built-in variant creating pragmas. In this particular case the surface shader was trying to use multi_compile_fwdbase but then the multi_compile_particles came after that and its keywords were added instead of the built-in lighting keywords. This is now fixed so that the particles keywords will be added on top of other potential built-in keywords, similar to how multi_compile_fog works for example.