Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Port] [2021.3] [UUM-64059] made ForwardLit and GBuffer passes of URP…
…'s speed tree shaders have the same c-buffer layout in vertex and fragment shaders when GPU instancing and Light Layer are enabled JIRA: [UUM-64059](https://jira.unity3d.com/browse/UUM-64059) This PR is to fix the error case where. shader compilation error logs about c-buffer layout mispatch in vertex and fragment shaders of URP speed tree 7 shader are repetitively printed out when the material enables GPU instancing and Use Rendering Layer in URP RP asset's lighting section is on. Because the speed tree shader is not compatible with SRP Batcher, the shader is supported by InstancingBatcher. When rendering request comes, the batcher collects layout informations about 'unity_Builtins0Array' through array of GPU program parameters defined by shader compilation result. For its vertex shader variant, `unity_LODFadeArray` is the first member of the c-buffer because the shader always enables `LOD_FADE_PERCENTAGE`. In addtion to that, `unity_RenderingLayerArray` becomes the second member because Light Layer, a `multi_compile` keyword is active, Unlikely, for its fragment shader variant, it still requires `unity_Builtins0Array`, but the `LOD_FADE_PERCENTAGE` keyword doesn't exist here, so the first member is determined to be `unity_RenderingLayerArray`, and the mismatch case occurs. For avoiding this, I simply changed their pragma action from `multi_compile_vertex` to `multi_compile`. And when I tested further, there are more places where the same problem happens, I applied this there too. So, affected places are... - `ForwardLit` pass in URP's SpeedTree7 shader - `GBuffer` pass in URP's SpeedTree7 shader - `ForwardLit` pass in URP's SpeedTree8 shader - `GBuffer` pass in URP's SpeedTree8 shader
- Loading branch information