Shadow cascades weird since 7.2.0

I've been getting a border at the edge of my shadow cascades since I updated to 7.2.0 (and now 7.2.1). Any ideas what could be causing this?

 

Same issue, I can't find the solution.

Work great with universal lit, but costume shader like Toony Colors Pro 2 (generate with 2.0) since 7.2.0 ( and 7.2.1) have strange glitch when shadow cascades is set to two or four.

It's work with no cascades.

 

My project is too big to send but my issue is probably because I’m using a custom terrain shader (as 99% of users probably are). According to asset store developers, there have been changes to shadowing in 7.2.0. and these have broken custom shaders.

I’m sure the developers will fix this at their end. What you could do at your end though, is communicate better with the said developers so they don’t get surprised by such changes. They shouldn’t have to find out via one star “it’s not working” user reviews.

 

this is not an issue of URP 7.2.0, but of the terrain shader that is still using 7.1.8 shader.

the light and shadow behavior are embeded inside the shader, so if you update to 7.2.0 without upgrading the terrain shader, this is what you get!

 

I have similar issues but I am not sure what to upgrade. It must be something to do with my shader, but I am not sure where to look at

Edit: this seems a good start: https://docs.unity3d.com/Packages/c...universal@7.2/manual/upgrade-lwrp-to-urp.html but didn't work

 

If you have a custom shader, this is very likely due to the shadowcoord computation.

it should be computed like this:

#if defined(REQUIRES_VERTEX_SHADOW_COORD_INTERPOLATOR)
output.shadowCoord = GetShadowCoord(vertexInput);
#endif

the new define is important, because apparently is not always true.

 

Cheers! This worked for me as well.

 

@sebas77 Hmm. Actually it removes the glitch but i've just noticed it's removed my terrain shadows as well!

 

Ouch that's all I had to do to make it work, but be sure it compiles if the define is true you may not have a vertex input defined and in that case you may need something else

 

Unity does such an amazingly crappy job of communicating or documenting changes to the shader. I spend all my time diffing stuff on GitHub after every release trying to figure out what they have broken or added. It makes SRP support a nightmare, and now consumes about 100% of my development time such that I have no time left to actually work on my project. Removing surface shaders and not replacing it with a similar abstraction layer is the stupidest thing Unity has ever done- it's made their engine the hardest engine to support shaders in when it was previously the easiest.

Also, the fix listed here doesn't work at all. Currently searching through change lists as none of this stuff is documented, as usual, thanks Unity.

 

it's very strange it worked for me with no problems, I have no clue tho

 

So the correct answer to this is that you have to compute the shadow coords in the fragment shader now:

Code (CSharp):

1. #if defined(MAIN_LIGHT_CALCULATE_SHADOWS)
2.    IN.shadowCoord = TransformWorldToShadowCoord(WorldSpacePosition);
3. #else
4.    IN.shadowCoord = float4(0, 0, 0, 0);
5. #endif

There may be more to it than this though- but with Unity's policy of never documenting shaders it's hard to know.

 

the actual c ode I use in the VS is this:

#if defined(REQUIRES_VERTEX_SHADOW_COORD_INTERPOLATOR)
o.shadowCoord = TransformWorldToShadowCoord(lwWorldPos);
#endif

and as far as I got in my case REQUIRES_VERTEX_SHADOW_COORD_INTERPOLATOR is actually false, so it's not even computed.

When I asked if it's ok if it's not computed, I have been told:

"But yes, the problem is that we removed screen space shadows so the shadow coords have to be computed a little bit differently and we also have better defines that needed to be changed."

but I did't investigate further because I have no knowledge of shadowing algorithms so I wouldn't understand anyway.

Edit: Oh Sorry you are right, I haven't noticed that in the fragment this code changed too:

#if defined(REQUIRES_VERTEX_SHADOW_COORD_INTERPOLATOR)
inputData.shadowCoord = input.shadowCoord;
#elif defined(MAIN_LIGHT_CALCULATE_SHADOWS)
inputData.shadowCoord = TransformWorldToShadowCoord(inputData.positionWS);
#else
inputData.shadowCoord = float4(0, 0, 0, 0);
#endif

This should the correct fix, as written by @Elvar_Orn

 

So I'm guessing they use the interpolator for light mapping and pixel computed for cascades.

 

This also broke my shadows. I guess I'll have to write to all the asset authors who wrote the shaders I'm using, and ask them to upgrade.

As this is now Unity's recommended default rendering pipeline for new projects, and since pacman always pulls the latest version of it, you should probably try to limit breaking changes as much as possible from here forward - documented or not. Changing an API between minor bugfix releases is for alpha software.

 

I'm also getting this in URP 7.3.1. Any guidance for people who have never patched Unity? Where can I start? I really want to fix this issue.

 

I'm pretty sur @Elvar_Orn just explained how to patch it two post above yours.

You can also do a diffcheck on Git to see what has been changed between your version and the new version.

 

Why do you have two input-structures in the fragment shader? "inputData" and "input"
I guess "input" is the Varyings structure, but what is inputData then. I would appreciate if you could calrify.

 

Pretty hilarious how when Unity went from 2019.3.7 to 2019.3.8 it took away the option of installing SRP below 7.3.1, even though 7.3.1 is full of breaking changes. Don't envy anyone whose job is to write shaders right now.

 

Hm, well at least there is some info on it here... Also just found my lighting broken since I've upgraded my project the other day (this shadow thing just being a few of them... I have a post processing pass relying on alpha that now renders my scene either black or as completely transparent).

- I don't get it though; it was working fine, so why this change? We now need extra calculations in our fragment shaders for the same effect, but isn't that a step backwards? Or did you previously handle this in the GetMainLight function that takes these shadow coordinates, and stripped it from there?

 

So I'm still having issues from this change - a new one reported. For some reason, the shadows just don't line up with what the Unity terrain shadows show:

Here's MicroSplat, with the changes above:



and here's the unity shader:



This is with 4 cascades.

In the pixel shader I do:

Code (CSharp):

1. #if defined(REQUIRES_VERTEX_SHADOW_COORD_INTERPOLATOR)
2.     inputData.shadowCoord = input.shadowCoord;
3. #elif defined(MAIN_LIGHT_CALCULATE_SHADOWS)
4.     inputData.shadowCoord = TransformWorldToShadowCoord(inputData.positionWS);
5. #else
6.     inputData.shadowCoord = float4(0, 0, 0, 0);
7. #endif
8.  
9.  
10.                 half4 color = UniversalFragmentPBR(

If I understand correctly, the vertex shader shouldn't matter here because we'll be taking the second pathway. And yes, inputData.positionWS is the world space position of the pixel.

 

I have a _MAIN_LIGHT_SHADOWS in my defines, has this changed ?

This all is EXTREMELY confusing, i just cant get my shadows right in a custom shader, is near impossible to spend months to do a simple thing like that because URP is changing 1000% every second and nothing is obvious or documented.

Please consider to remove the pipelines from users production lines as nothing works between versions, is strange to send for production a pipeline that is not even in pre-pre-pre-beta stage.

Also there is zero consideration of users that stated projects in other than latest Unity, right now is impossible to know what Unity and URP to use, and noone knows if anything will be working in just next version of Unity or URP, it is an impossible situation.

The pipelines scheme is just extremely confusing and hard to keep up with and should be labeled as extremely experimental and as an extreme risk to use in a project by Unity, to showcase their exact nature and prevent users from putting their hard work to such a huge risk.

Also is now obvious why point light shadows take forever to create, the URP is just extremely complex and not user friendly for any advanced production and shader programming. On top of that it changes every minute completly, so even if spend months and make something in one version, the next day maybe broken and have to start all over with totally new things and handling. It is just nowhere near ready to use in production besides the simplest of projects perhaps.