[3.x] Fix alpha scissor shadow casting support

[Ansraer]

3.x version of #58954, should fix #58924.

[clayjohn]

should fix #58924.

Did you test the MRP in #58924?

[Ansraer]

Yes, appears to work the way it should:

Screenshot

Just noticed that my one-line change managed to break the mono build. No clue how that happened...

[Ansraer]

Huh, just forcing it to run again fixed it.

[Calinou]

Yes, appears to work the way it should:

PS: You need to add a blank line after <details> (or <summary>) for Markdown to work inside the collapsed block. I edited your comment accordingly, but remember to do this in the future 🙂
The same applies to GitHub attachment video previews, by the way. They require a blank line before and after the link.

[clayjohn]

The logic is escaping me, so I am going to write some notes about how I understand what is going on:

First has_alpha is created with two parts has_base_alpha and has_blend_alpha. has_blend_alpha is true if a blend mode other than mix is used (in the MRP, blend mode mix is used) so has_blend_alpha should be false. has_base_alpha is true if the shader uses the screen texture, the depth texture or if it writes to ALPHA without using the alpha scissor. The MRP does not use screen texture or depth texture and uses alpha scissor so has_base_alpha should be false. Therefore, has_alpha should be false.

https://github.com/godotengine/godot/blob/a88a0501339a3d0741a1f421b778396e84200775/drivers/gles3/rasterizer_scene_gles3.cpp#L2281-L2283

Then we get to your change. You have added a check to whether alpha scissor is used. This way, even if an object has alpha, it will be forced into the opaque pass if alpha scissor is used.
https://github.com/godotengine/godot/blob/a88a0501339a3d0741a1f421b778396e84200775/drivers/gles3/rasterizer_scene_gles3.cpp#L2326

But, following the logic above, when alpha scissor is used, has_alpha should only be true if using depth texture, screen texture, or a non-mix blend mode. The MRP doesn't use any of those, so has_alpha should not be true. so your PR shouldn't fix this bug, but it does!

Okay, on reflection, I don't think this is the right approach for two reasons:

1. This will force objects that read from depth texture and screen texture into the opaque pipeline if they use alpha scissor which will break those objects (screen texture is captured after the opaque pass and you can't read from and write to depth at the same time).
2. We need to figure out why has_alpha is true despite the fact that all the conditions should be false. My guess is that a condition is being set incorrectly somewhere leading to has_alpha being true when it shouldn't.

[Ansraer]

Fair enough, I will look into it again tomorrow.

[Ansraer]

Had some spare time to look into this again. You were right, there was a significantly cleaner solution to this than to just assume that everything with alpha scissors was either fully transparent or opaque.

[clayjohn]

Great work!

[akien-mga]

Thanks!

[akien-mga]

Cherry-picked for 3.4.4.